/ 


NAVAL  POSTGRADUATE  SCHOOL 
Monterey ,  California 


Modeling  and  Simulation  of  Fleet  Air  Defense  Systems 
Using  EADSIM 

by 

Neil  Robert  Bourassa 
June  1993 

Thesis  Advisor:  Robert  E.  Ball 


Approved  for  public  release:  distribution  is  unlimited. 


93-27996 


REPORT  DOCUMENTATION  PAGE 

Form  Approved 

0MB  No  0704-0188 

PuOhc  reporting  burden  for  this  coJiemon  ot  information  is  estimated  to  average  *  hoof  per  response,  mcJgdmg  the  time  for  reviewing  mstruaions.  searching  existing  data  sources, 
gathering  and  maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this 
collection  of  information,  including  suggestions  tor  reducing  this  burden  to  Washington  Headquarters  Services.  Direaorate  for  information  Operations  and  Reports.  1 2 1 S  Jefferson 
Oavis  Highway,  Suite  1204.  Arlington.  VA  22202'4302  and  to  the  Office  of  Management  and  Budget.  Paperwork  Reduction  Project  (0  704-0 1B8).  Washington.  DC  20503 

1.  AGENCY  USE  ONLY  (Leave  blank)  2.  REPORT  DATE  3.  REPORT  TYPE  AND  DATES  COVERED 

June  1993  Master's  Thesis 

4.  TITLE  AND  SUBTITLE 

Modeling  and  Simulation  of  Fleet  Air  Defense  Systems 

Using  EADSIM 

5.  FUNDING  NUMBERS 

6.  AUTHOR(S) 

Bourassa,  Neil  Robert 

7.  PERFORMING  ORGANIZATION  NAME(S}  AND  AOORESS(ES) 

Naval  Postgraduate  School 

Monterey,  CA  93943-5000 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

9.  SPONSORING /MONITORING  AGENCY  NAME(S)  AND  AODRESS(ES) 

10.  SPONSORING /MONITORING 

AGENCY  REPORT  NUMBER 

11.  SUPPLEMENTARY  NOTES 

The  views  expressed  in  this  thesis  are  those  of  the  author  and  do  not  reflect  the 
official  policy  or  position  of  the  Department  of  Defense  or  the  U.o.  Government. 

12a.  DISTRIBUTION  /  AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  is  unlimited. 

12b.  DISTRIBUTION  CODE 

13.  ABSTRACT  (Maximum  200  words) 

The  goal  of  this  thesis  is  to  develop  a  capability  to  simulate  naval  anti-air  warfare  (AAW)  systems  at  the  Naval 
Postgraduate  School  (NPS).  Students  in  many  curricula  at  NPS  can  use  such  a  model  in  thesis  research  or  course 
work  related  to  air  defense.  Examples  of  courses  in  the  Department  of  Aeronautics  and  Astronautics  in  which 
there  is  a  use  for  AAW  simulation  are  AE3705  "Air  Defense  Lethality"  and  AE3251  "Aircraft  Combat 
Survivability".  The  Extended  Air  Defense  Simulation  (EADSIM)  was  selected  as  the  model  to  acquire  and  install 
on  the  Silicon  Graphics  computer  workstations  of  the  Computer  Center  Visualization  Laboratory.  EADSIM  was 
developed  by  Teledyne  Brown  Engineering  for  the  U.S.  Army  Space  and  Strategic  Defense  Command  and  is  a 
powerful  analysis  tool  that  can  model  many  aspects  of  air  warfare.  The  author  has  used  EADSIM  to  develop 
AAW  and  Strike  Warfare  scenarios  for  use  in  AE3705  and  AE3251.  These  scenarios  required  the  creation  and 
modification  of  platforms  within  the  graphical  user  interface  to  simulate  naval  units.  These  scenarios  can  be  run 
and  displayed  as  animated  playback  files  for  analysis.  In  addition,  the  EADSIM  weapon  performance  model  was 
studied.  The  default  values  for  weapon  systems  probability  of  kill  (P^)  were  modified,  and  the  results  were 
examined  to  determine  the  overall  effect  of  P^^  within  a  simulation. 

14.  SUBJECT  TERMS 

Modeling,  Simulation,  Air  Defense,  EADSIM 

15.  NUMBER  OF  PAGES 

129 

16.  PRICE  CODE 

17.  SECURITY  CLASSIFICATION 
OF  REPORT 

UNCLASSIFIED 

18.  SECURITY  CLASSIFICATION 
OF  THIS  PAGE 

UNCLASSIFIED 

19.  SECURITY  CLASSIFICATION 
OF  ABSTRACT 

UNCLASSIFIED 

20.  LIMITATION  OF  ABSTRACT 

UL 

NSN  7540-01-280-5500 


1 


Standard  Form  298  (Rev  2-89) 

Ofwcribed  by  ansi  Std  £39->8 


Approved  for  public  release;  distribution  is  unlimited. 


Modeling  and  Simulation  of  Fleet  Air  Defense  Systems 
Using  EADSIM 


by 


Neil  Robert  Bourassa 

Lieutenant  Commander,  United  States  Navy 
B.S.,  United  States  Naval  Academy,  1982 

Submitted  in  partial  fulfillment  of  the 
requirements  for  the  degree  of 

MASTER  OF  SCIENCE  IN  ENGINEERING  SCIENCE 


from  the 

NAVAL  POSTGRADUATE  SCHOOL 
June  1993 


Author: 


Approved  by: 


Neil  Robert  Bourassa 

4^ 


Robert  E.  Ball,  Thesis  Advisor 
^illiarri^B.  Colson,  Second  Reader 

_ i 

aniel  J.  CoUins,  ^hcffman,  Deparfm^t  of  Aeronautics 
and  Astronauf 


ABSTRACT 


The  goal  of  this  thesis  is  to  develop  a  capability  to  simulate  naval  anti-air  warfare 
(AAW)  systems  at  the  Naval  Postgraduate  School  (NFS).  Students  in  many  curricula  at 
NPS  can  use  such  a  model  in  thesis  research  or  course  work  related  to  air  defense. 
Examples  of  courses  in  the  Department  of  Aeronautics  and  Astronautics  in  which  there 
is  a  use  for  AAW  simulation  are  AEi705  "Air  Defense  Lethality"  and  AE3251  "Aircraft 
Combat  Survivability".  The  Extended  Air  Defense  Simulation  (EADSIM)  was  selected 
as  the  model  to  acquire  and  install  on  the  Silicon  Graphics  computer  workstations  of  the 
Computer  Center  Visualization  Laboratory.  EADSIM  was  developed  by  Teledyne  Brown 
Engineering  for  the  U.S.  Army  Space  and  Strategic  Defense  Command,  and  is  a  powerful 
analysis  tool  that  can  model  many  aspects  of  air  warfare.  The  author  has  used  EADSIM 
to  develop  AAW  and  Strike  Warfare  scenarios  for  use  in  AE3705  and  AE3251.  These 
scenarios  required  the  creation  and  modification  of  platforms  within  the  graphical  user 
interface  to  simulate  naval  units.  These  scenarios  can  be  run  and  displayed  as  animated 
playback  files  for  analysis.  In  addition,  the  EADSIM  weapon  performance  model  was 
studied.  The  default  values  for  weapon  systems  probability  of  kill  (Pk)  were  modified, 
and  the  results  were  examined  to  determine  the  overall  effect  of  Pj.  within  a  simulation. 
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I.  INTRODUCTION 


A.  BACKGROUND  ON  AIR  DEFENSE  MODELING 

Air  defense,  a  critical  aspect  of  modem  combat,  is  defined  in  the  JCS  Dictionary  as 

...all  defensive  measures  designed  to  destroy  attacking  enemy  aircraft  or  missiles 
in  the  earth's  envelope  of  atmosphere,  or  to  nullify  or  reduce  the  effectiveness  of 
such  an  attack.  [Ref  1] 

Anti-air  warfare  (AAW)  is  the  term  used  by  the  United  States  Navy  for  air  defense  and, 
in  the  context  of  fleet  operations,  is  an  entire  warfare  area.  The  U  S.  Navy's  definition 
of  AAW  is: 

...  that  action  required  to  destroy  or  reduce  to  an  acceptable  level  the  enemy  air  and 
missile  threat.  It  includes  such  measures  the  use  of  interceptors,  bombers, 
antiaircraft  guns,  surface-to-air  missiles,  electronic  countermeasures,  and  destruction 
of  the  air  or  missile  threat  both  before  and  after  it  is  launched.  Other  measures 
which  are  taken  to  minimize  the  effects  of  hostile  air  action  are:  cover, 
concealment,  dispersion,  deception  (including  electronic),  and  mobility.  [Ref  2] 

For  the  purpose  of  this  thesis,  the  terms  AAW  and  air  defense  will  be  considered  to  be 

synonymous. 

To  the  warfare  qualified  Military  Officer,  the  study  of  air  defense  is  highly  pertinent. 
Consequently,  there  exists  a  need  for  an  extensive  anti-air  warfare  computer  model  at  the 
Naval  Postgraduate  School  (NPS).  This  model  should  be  incorporated  into  the 
NPS/NAVAIR  Sun^ivability  and  Lethality  Assessment  Center  (SLAC).  The  SLAC 
currently  contains  most  of  the  standard  programs  for  assessing  the  survivability  of  Blue 
aircraft  against  a  Red  air  defense.  However,  it  lacks  a  model  for  Blue  AAW  against  a 
hostile  air  attacks.  Such  a  model  can  also  be  used  in  many  different  courses  of  study 
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Curricula  where  air  defense  modeling  may  be  used  include  Aeronautics,  C^I,  Operations 
Research,  and  Combat  Systems  Engineering. 

Air  defense  modeling  can  be  described  as  the  simulation  of  actions,  events,  and 
encounters  between  computer  generated  aircraft,  sensors,  targets,  and  weapon  systems. 
A  variety  of  air  defense  computer  models  have  been  produced  by  various  branches  of  the 
Department  of  Defense.  Most  of  these  models  are  described  in  the  Catalog  of  Wargaming 
and  Military  Simulation  Models  [Ref  3]  which  lists  the  models,  simulations  and  war 
games  used  throughout  the  Department  of  Defense.  A  model  is  "a  physical, 
mathematical,  or  otherwise  logical  representation  of  a  system,  entity,  phenomenon,  or 
process."  [Ref  4]  A  simulation  is  "a  method  for  implementing  a  model  over  time."  [Ref 
4]  It  also  is  "a  technique  for  testing,  analysis,  or  training  in  which  real-world  systems  are 
used,  or  where  real  world  and  conceptual  systems  are  reproduced  by  a  model."  [Ref.  4] 

Models  can  range  from  high  fidelity,  single  target  (one-on-one)  models,  to  lower 
fidelity  but  complex  (many-on-many)  simulations.  Some  models  concentrate  on  a  specific 
aspect  of  AAW,  such  as  missile  fly-out,  with  very  high  fidelity.  Others,  such  as  theater 
level  simulations,  are  concerned  with  a  higher  scope  of  conflict.  In  this  case,  an  entire 
battlefield  may  be  modeled,  with  the  associated  engagements  and  outcomes  determined 
by  a  particular  scenario  run. 

All  services  have  developed  a  variety  of  air  defense  models  for  their  own  use,  some 
are  used  jointly.  Different  levels  of  fidelity  are  required  based  on  the  user's  needs.  No 
one  model  can  do  everything  for  everyone.  Thus,  specific  models  have  been  produced 
for  specific  tasks.  The  needs  of  the  user  determine  the  scope  and  fidelity  of  the  model. 


B.  MODELING  REQUIREMENTS  AT  NFS 

At  the  Naval  Postgraduate  School,  students  often  need  to  evaluate  the  effectiveness 
of  a  specific  weapon  system  against  a  certain  target.  In  the  realm  of  air  defense,  one  is 
concerned  with  the  effectiveness  of  friendly  anti-air  weapons  against  an  airborne  threat. 
This  topic  is  covered  in  great  detail  in  the  course  AE3705  "Air  Defense  Lethality".  Other 
students  may  be  concerned  with  the  survivability  of  friendly  aircraft  against  a  hostile  air 
defense.  This  is  addressed  in  AE3251  "Aircraft  Combat  Survivability".  In  both  courses, 
the  use  of  an  air  defense  computer  model  is  an  assigned  homework  problem.  The  Air 
Defense  Lethality  problem  deals  with  the  effectiveness  of  surface-to-air  missiles  (SAMs), 
anti-aircraft  artillery  (AAA)  and  small  arms  fire  against  an  attacking  aircraft.  The  Aircraft 
Combat  Survivability  problem  looks  at  the  survivability  of  an  aircraft  attacking  a  target 
defended  by  hostile  SAMs  and  anti-aircraft  guns. 

The  computer  simulation  currently  used  in  the  class  assignments  resides  in  the  NFS 
mainframe  and  is  somewhat  out  of  date.  Newer  computer  simulations  are  now  available 
that  take  advantage  of  the  processing  power  and  graphical  user  interface  (GUI)  of  today's 
computer  workstations.  Many  of  the  air  defense  simulations  listed  in  the  Catalog  of 
Wargaming  and  Military  Simulation  Models  have  been  written  to  nm  on  desktop 
workstations.  As  a  result,  finding  the  appropriate  model  to  use  at  NFS  not  only  requires 
finding  the  appropriate  software,  but  also  the  available  computer  system  in  which  to  nm 
it  on.  To  complicate  the  problem,  the  software  may  have  certain  hardware  requirements. 
This  may  be  a  function  of  random  access  memory  (RAM),  storage  capacity  (hard  disk), 
or  graphical  capability  of  the  computer.  Fortunately,  the  Catalog  of  Wargaming  and 
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Military  Simulation  Models  lists  the  system  requirements  along  with  the  model's 
description. 

C.  ISSUES  THAT  IMPACT  AAW  MODELING 

To  facilitate  the  selection  of  an  appropriate  air  defense  model  for  use  at  the  Naval 
Postgraduate  School,  one  must  consider  some  relevant  issues.  In  this  post  Cold  War  era, 
the  military  is  faced  with  an  ever  shrinking  defense  budget.  Consequently,  less  expensive 
methods  must  be  developed  to  train  and  educate  the  military.  In  addition,  procurement 
of  new  weapon  systems  will  under  come  much  more  scrutiny  as  compared  with  projects 
of  the  previous  decade.  Computer  modeling  and  simulation  are  powerful  and  vaJuable 
tools,  and  are  an  available  method  to  investigate  a  problem  and  come  to  a  logical  solution. 
In  almost  every  case,  a  real  world  scenario  can  be  simulated  on  a  computer  at  a  greatly 
reduced  cost. 

1.  Current  Military  Operations 

The  first  issue  to  be  discussed  is  the  climate  of  today's  military  operations. 
Besides  stopping  the  spread  of  aggression  as  in  Desert  Shield/Desert  Storm,  the  military 
may  be  called  upon  to  act  as  a  peacekeeping  force.  This  is  exemplified  by  American 
participation  in  U.N.  sponsored  intervention  in  Bosnia.  Efforts  like  the  humanitarian  aid 
in  Somalia  will  also  continue  as  the  need  exists.  Furthermore,  the  protection  of  vital 
national  interests  and  those  of  U.S.  allies  are  important  roles  of  the  military. 

The  U.S.  Navy's  white  paper.  From  the  Sea,  describes  a  naval  force  operating  in 
littoral  waters  [Ref  5].  Ships  operating  in  these  coastal  waters  may  be  subject  to  attack 
by  tactical  jet  aircraft  and  sea-skimming  anti-ship  missiles.  As  a  force,  the  Navy  must 
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be  able  to  deal  with  such  threats  and  continue  with  the  mission  at  hand.  Developing  the 
ability  to  model  such  a  scenario  is  a  key  goal  of  this  project. 

2.  Current  Threats  and  Threat  Areas 

The  military  is  no  longer  operating  in  a  bipolar  world.  As  a  result,  the  threat  of 
hostile  emerging  nations  is  real.  Such  a  threat  can  be  generic,  but  the  systems  that 
compose  that  threat  are  state  of  the  art.  An  example  of  a  specific  threat  to  naval  forces 
is  the  anti-ship  cruise  missile.  It  is  possible  to  build  a  data  base  that  contains  known  or 
potential  threats  and  incorporate  these  into  the  simulation.  Such  a  capability  is  essential 
if  the  model  is  to  be  flexible  and  useful. 

The  current  geopolitical  situation  shows  that  the  Middle  East  will  continue  to  be 
a  major  concern.  Other  potential  threats  include  the  Korean  peninsula  and  the  Balkans. 
A  theater  level  model  must  be  able  to  simulate  any  of  those  regions  as  well  as  other  area 
on  the  globe.  Again,  flexibility  of  the  model  will  make  it  a  more  useful  tool. 

3.  Future  Threats 

The  threats  that  may  present  themselves  today  may  not  necessarily  be  the  threats 
of  tomoiTov> .  An  example  of  the  proliferation  of  a  new  threat  is  the  number  of  countries 
that  have  obtained  a  Theater  Ballistic  Missile  (TBM)  c^ability.  Future  threats  may 
include  low  observable  missiles  and  aircraft,  advanced  radar  systems,  and  directed  energy 
weapons.  The  ability  of  a  model  to  grow,  adapt  and  be  capable  of  simulating  future 
threats  also  adds  to  its  usefulness. 
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4.  Expected  Value  Models  versus  Monte  Carlo  Models 

The  specific  outcome  of  any  air  defense  scenario  is  unpredictable  or  random,  (e.g. 
one  aircraft  may  be  killed  or  five  aircraft  may  be  killed  in  a  given  scenario).  There  are 
two  methods  of  simulation  for  this  random  process,  the  Expected  Value  method  and  the 
Monte  Carlo  method.  In  the  Expected  Value  method,  the  simulation  is  run  once  using 
individual  weapon  kill  probabilities,  and  a  prediction  is  made  with  respect  to  the 
probability  of  specific  outcomes  (e.g.  a  55%  probability  one  aircraft  and  a  10% 
probability  five  aircraft  are  killed).  The  Expected  Value  of  aircraft  kills  for  this  scenario 
is  determined  from  the  descrete  probability  distribution  function  of  aircraft  killed,  (e  g. 
the  expected  number  of  aircraft  kills  is  2.3).  Expected  Value  simulations  use  a  set  of 
probabilities  for  the  different  factors  being  modeled  and  the  model  is  run  only  once.  With 
an  expected  value  model,  identical  results  will  be  produced  each  time  the  simulation  is 
conducted. 

In  the  Monte  Carlo  method,  the  weapon  kill  probabilities  are  used  in  conjunction 
with  random  draws  to  determine  a  "yes  or  no"  outcome  for  each  encounter  (e.g.  the 
aircraft  is  killed).  A  Monte  Carlo  simulation  consists  of  running  the  model  multiple  times 
for  each  scenario.  Each  "run"  uses  a  different  random  number  seed,  which  gives  different 
results  for  each  simulation  of  a  particular  scenario  (e.g.  four  aircraft  are  killed  in  run  one 
and  two  aircraft  are  killed  in  run  two).  Combining  the  results  from  each  Monte  Carlo  run 
provides  the  user  with  a  composite  set  of  results.  These  results  may  be  plotted  on  a 
histogram  for  further  analysis. 
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5.  Other  Required  Capabilities 

The  capability  to  represent  both  surface  ships  and  naval  air  units  is  essential  for 
the  modeling  of  naval  AAW.  Representation  of  ground  forces,  although  not  necessary, 
is  recommended.  A  graphical  output  for  analysis  is  strongly  desired,  as  is  the  ability  of 
the  model  to  do  Monte  Carlo  simulations.  Two  way  simulations  (Red-on-Blue  and  Blue- 
on-Red)  is  desirable,  as  is  the  modeling  of  Command,  Control,  Communications,  and 
Intelligence  (C^I).  Other  desirable  features  include  a  missile  fly-out  model  where  the 
trajectory  of  the  weapon  is  calculated.  Electronic  Warfare  (EW),  and  terrain  modeling. 

D.  SELECTING  A  MODEL 
1.  Sources 

In  order  to  select  the  most  appropriate  air  defense  model  to  use  at  NPS,  the  author 
investigated  all  possible  sources.  The  Catalog  of  Wargaming  and  Military  Simulation 
Models,  which  has  inputs  from  many  of  the  analysis  agencies  in  the  various  defense 
establishments,  independent  contractors,  and  research  organizations,  was  the  primary 
source.  Other  sources  of  information  included  the  research  desk  at  the  Dudley  Knox 
Library  of  NPS.  An  internal  computer  search  yielded  listings  of  documents  held  within 
the  library,  including  completed  thesis  work  on  similar  topics  [Ref  6].  An  external 
computer  search  through  the  Dialog  Service,  yielded  public  domain  material  on  the  topic 
of  air  defense  models  and  simulations  [Ref.  7].  The  search  also  included  listings  of 
related  information  from  NATO  allies  through  international  access. 
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2.  The  Available  AAW  Models 

Appendix  A  lists  a  selection  of  AAW  models  and  simulations  that  were  considered 
to  be  suitable  for  this  project.  Although  it  is  not  a  comprehensive  list  of  AAW 
simulations,  it  contains  a  brief  description  of  the  models  which  were  given  consideration. 
The  models  listed  range  from  specific,  single  purpose  models  to  theater  level  battlespace 
simulations.  The  models  listed  in  Appendix  A  were  studied  in  particular  to  determine 
their  applicability  to  the  simulation  of  naval  AAW  at  NFS.  Some  of  the  models  listed 
are  no  longer  available,  while  others  are  not  yet  in  service.  The  higher  fidelity  models 
are  often  limited  to  one-on-one  engagements.  These  are  satisfactory  for  analysis  of  a 
specific  aspect  of  AAW,  but  they  do  not  offer  the  versatility  of  a  larger  scale  simulation. 
The  larger  models,  though  sometimes  lacking  in  detail,  often  allow  the  simulation  of  more 
of  the  aspects  of  AAW.  The  selection  must  be  made  based  upon  the  users'  needs, 
recognizing  the  fact  that  one  model  cannot  do  all  things  for  ail  users. 

3.  Computer  Systems  at  NFS 

There  are  a  large  variety  of  computer  systems  at  the  Naval  Fostgraduate  School. 
A  number  of  computer  laboratories  exist  that  are  dispersed  throughout  the  academic 
buildings.  These  labs  are  mostly  comprised  of  desktop  personal  computers  and 
workstations,  such  as  the  Sun  SPARCStations  in  the  Fhysics  Department  Simulation  Lab 
and  the  Silicon  Graphics  Incorporated  (SGI)  Iris/Indigo  workstations  in  the  Aeronautics 
and  Astronautics  Computer  Lab.  However,  mini-mainframes,  an  AMDAHL  mainframe, 
and  a  new  Cray  computer  are  also  in  service  at  NFS.  One  determining  factor  in  selecting 
a  computer  model  is  that  the  hardware  must  be  available  on  which  to  run  the  simulation. 
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4.  Choosing  the  Model 

The  Extended  Air  Defense  Simulation  (EADSIM),  developed  by  Teledyne  Brown 
Engineering  (TBE),  was  selected  as  the  basis  for  this  thesis.  This  decision  was  based  on 
the  capabilities  of  the  simulation  and  the  available  hardware.  EADSIM  is  a  Monte  Carlo 
simulation  that  offers  a  high  level  of  flexibility  at  an  acceptable  level  of  fidelity. 
Although  EADSIM  was  not  originally  designed  for  Naval  AAW  modeling  and  simulation, 
it  can  represent  employment  of  the  many  systems  currently  in  fleet  use.  Most  naval 
aircraft  are  also  modeled  in  EADSIM,  and  others  can  be  created  as  will  be  discussed  in 
later  portions  of  this  thesis.  The  most  striking  feature  of  EADSIM  is  the  graphical 
playback.  Any  scenario  run  can  be  played  back  in  two  or  three  dimensions.  Two 
dimensional  playback  is  superimposed  over  a  map  of  the  modeled  battlefield.  Three 
dimensional  playback  shows  terrain  elevation,  altitude  changes  of  aircraft,  and  TBM  flight 
profiles.  This  playback  capability  gives  the  operator  the  ability  to  view  the  results  of  any 
scenario  run.  The  greatest  shortcoming  of  the  model,  however,  is  a  lack  of  missile  flyout 
in  an  anti-air  engagement.  This  problem  has  been  addressed  by  other  EADSIM  users  and 
will  be  discussed  later  in  this  thesis. 

The  U.S.  Army  Space  and  Strategic  Defense  Command  (SSDC)  supports  EADSIM 
through  its  Test  Bed  Product  Office.  Software  management,  configuration  and  control  are 
accomplished  with  the  assistance  of  the  Army  Missile  Command  (MICOM).  These 
organizations  are  very  effective  in  supporting  the  program  and  have  enabled  the  NPS  to 
become  a  licensed  site  for  the  operation  of  EADSIM.  The  Test  Bed  Product  Office  also 
sponsors  system  training,  a  quarterly  newsletter,  and  the  EADSIM  User's  Group. 
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E.  THESIS  GOALS  AND  ORGANIZATION 


The  goals  of  this  thesis  are  to  develop  develop  a  capability  to  simulate  naval  AAW 
systems  at  NPS,  to  produce  AAW  and  Strike  Warfare  scenarios  for  use  in  AE3705  and 
AE3251,  and  to  investigate  the  weapon  performance  model  of  the  system  selected.  The 
thesis  is  organized  as  follows.  Chapter  II  gives  an  overview  of  the  model,  EADSIM,  as 
well  as  some  background  and  historical  information.  The  operation  of  EADSIM  is  the 
topic  of  Chapter  HI.  Chapter  IV  is  a  description  of  the  scenarios  developed  for  this 
project.  This  is  followed  by  the  execution  of  these  scenarios  in  Chapter  V.  Chapter  VI 
looks  at  an  engineering  application  of  the  model.  A  study  of  the  overall  effect  of  weapon 
system  probability  of  kill  (P^)  investigated  for  a  given  scenario.  Chapter  VII  examines 
the  future  of  EADSIM,  its  continued  development,  and  a  comparison  is  made  of 
EADSIM  with  ACES/Phoenix,  another  new  air  defense  model  at  NPS.  The  continued  use 
of  EADSIM  at  NPS  and  the  conclusions  this  thesis  are  the  topic  of  Chapter  VUI. 
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II.  THE  EXTENDED  AIR  DEFENSE  SIMULATION 


A.  EADSIM  OVERVIEW 

The  Extended  Air  Defense  Simulation,  or  EADSIM,  is  a  theater  level,  anti-air  warfare 

computer  model.  It  is  described  in  its  Executive  Summary  as: 

...  an  effective  and  powerful  tool  for  evaluating  the  effectiveness  of  various 
Command,  Control,  Communications  and  Intelligence  (C3I),  theater  missile 
defense,  and  air  defense  architectures,  as  well  as  weapon  systems  in  the  full  context 
of  an  environment  of  sensors.  Command  and  Control  (C2)  centers,  communications 
systems,  platform  dynamics,  and  weapons  performance.  It  models  both  Red  and 
Blue  forces  and  is  graphics-based,  user-oriented,  and  highly  versatile.  [Ref  8:p. 
vii] 

Originally  known  as  C3ISIM,  the  model  was  developed  as  a  prototype  for  the  U.S.  Army 
Strategic  Defense  Command  (SDC),  now  the  Space  and  Strategic  Defense  Command 
(SSDC),  and  the  U.S.  Army  Missile  Command  (MICOM).  The  prime  contractor. 
Teledyne  Brown  Engineering  (TBE),  was  tasked  to  produce  a  low-cost,  interim  analysis 
model  for  Extended  Air  Defense  Concepts  until  the  Extended  Air  Defense  Test  Bed 
(EADTB)  is  developed  [Ref  8;p.  1-1]. 

1.  Model  Description 

EADSIM  is  a  unique  analytic  model  of  air  and  missile  warfare.  Written  in  C 
computer  language  and  comprising  some  300,000  lines  of  computer  code,  it  separately 
models  each  imit  (ship,  aircraft,  missile  battery)  as  well  as  the  interaction  between  units. 
Scenarios  may  be  small  few-on-few  engagements,  or  large  many-on-many  battlefield  and 
theater  level  simulations.  These  scenarios  can  be  a  combination  of  land,  sea,  and  air 
battles.  A  unique  feature  of  EADSIM  is  that  it  simulates  concurrent  Red-on-Blue  and 
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Blue-on-Red  encounters.  This  enables  simultaneous  active  engagements  of  both  sides’ 
offensive  and  defensive  forces  to  be  employed  in  a  single  scenario.  [Ref  9] 

2.  Modeling  Capabilities 

EADSIM  can  model  a  wide  variety  of  offensive  and  defensive  anti-air  warfare 
(AAW)  scenarios.  Certain  aspects  of  Electronic  Warfare  (EW)  can  be  modeled,  along 
with  numerous  aspects  of  Command,  Control,  Communications,  and  Intelligence  (C^I) 
Terrain  is  accurately  modeled  with  the  use  of  the  Defense  Mapping  Agency  (DMA)  data 
of  the  world.  The  DMA  library  is  available  on  compact  disk  read  only  memory  (CD- 
ROM)  and  can  be  directly  read  into  a  scenario.  Table  I  depicts  the  general  areas  modeled 
by  EADSIM  as  listed  in  the  Executive  Summary  [Ref  8:p.  2-11.  EADSIM  is  not  limited 
to  the  modeling  areas  listed  in  Table  I,  nor  does  it  perform  each  of  the  above  functions 
equally  well.  Table  I  does,  however,  reflect  some  of  the  overall  capability  of  the  model 
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TABLE  I  -  AREAS  MODELED  WITH  EADSIM 


Air  Defense 

-  Surface-to-Air  Missiles 

"  Antiaircraft 
”  Antimissile 

-  Command  and  Control 

-  Air  Picture  Production  and 
Dissemination 

Air  Operations 

-  Defense  Counter-Air 

-  Offensive  Counter-Air 

-  Suppression  of  Enemy  Air  Defenses 
(SEAD) 

-  Deep  Interdiction 
Air  Bases 
Surveillance 

Surface-to-Surface  Artillery 

-  Command  and  Control 

-  Fire  Units 

-  Intelligence  Gathering  and 
Processing 


Generic  Noncombatants 
Communications 

-  Networks 

-  Devices 

-  Individual  Messages 
Electronic  Warfare 

-  Jamming  of  Sensors  and  Comms 

-  SIGINT  Detection  in  Support  of 
Artillery 

Terrain 

-  Sensor  Masking 

-  Communications  Propagation 

-  Flight/Movement 
Areas  of  Interest 

-  Track  Area  of  Interest 

-  Missile  Engagement  Zone  (MEZ) 

-  Fighter  Engagement  Zone  (FEZ) 

-  Area  of  Responsibility 

-  Theater  Missile  Defense  Area 
(TMDA) 


B.  HARDWARE  REQUIREMENTS 

The  Extended  Air  Defense  Simulation,  in  its  current  form  (software  Version  2.07),  is 
run  on  a  Silicon  Graphics  4-D  Series  (or  better)  workstation.  Desirable  hardware 
capabilities  for  EADSIM  include:  a  24-bit  graphics  plane;  64  Megabytes  of  random 
access  memory  (RAM);  and  1.2  Gigabytes  of  hard  disk  storage  space.  The  24-bit 
graphics  plane  is  essential  for  system  operation.  It  provides  a  graphics  buffering 
capability  for  the  processing  of  EADSIM.  The  software  will  operate  on  as  little  as  8 
Megabytes  of  RAM,  however,  the  scenarios  should  be  small  for  a  lower  capacity  system 
and  program  operation  is  very  slow.  Tests  have  shown  that  the  amount  of  RAM  directly 
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reflects  the  system  speed  and  time  required  for  a  scenario  run  [Ref  10],  Actual  hard  disk 
storage  requirements  also  vary  based  upon  user  scenario  applications.  The  executable 
files  alone  occupy  approximately  150  Megabytes  of  storage.  Other  recommended 
hardware  includes  a  personal  computer  with  commercial  software  applications.  Programs 
such  as  spreadsheets  and  plotting  routines  assist  in  the  manipulation  of  output  data  A 
printer  with  a  serial  interface  will  complement  the  system  by  printing  statistics  reports  for 
analysis. 

As  with  most  computer  workstation  applications.  EADSIM  operates  under  the  UNIX 
operating  system.  The  Silicon  Graphics’  version  of  UNIX  is  known  as  IRIX.  Silicon 
Graphics  created  IRIX  for  specific  use  in  their  computers.  Because  UNIX  has  been  in  use 
since  the  late  1960's,  it  has  gone  through  many  revisions.  Hence,  most  workstation 
manufacturers  optimize  the  operating  system  for  their  own  hardware.  It  is  noteworthy  that 
most  naval  tactical  decision  aids  also  run  under  UNIX, 

C.  SOFTWARE  INSTALLATION 

The  initial  installation  of  the  EADSIM  software  was  not  easy.  The  Aeronautics  and 
Astronautics  computer  lab  has  three  SGI  Iris/Indigo  workstations.  Unfortunately,  they  are 
not  24-bit  graphics  capable.  Upgrading  the  computers  to  the  EADSIM  system 
requirements  is  cost  prohibitive.  These  upgrades  would  cost  twelve  thousand  dollars  per 
computer,  which  is  more  than  the  original  purchase  price  of  each  system.  Consequently, 
the  Computer  Center  Visualization  Laboratory's  (Vis  Lab)  Silicon  Graphics  Power  Series 
380/VGX  was  selected  as  the  host  computer  for  EADSIM.  The  only  shortcoming  of  the 
computer  initially  was  a  lack  of  adequate  internal  hard  disk  storage.  The  purchase  of  a 
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new  2.1  Gigabyte  hard  disk  for  this  project  proved  to  be  the  most  cost  effective  method 
in  which  to  install  EADSIM  at  NPS.  The  open  source  requisition  took  longer  than 
anticipated.  While  awaiting  the  arrival  of  tlie  new  hard  disk,  the  Physics  Simulation 
Laboratory's  (Sim  Lab)  file  server  was  used  as  the  host.  Use  of  the  Simulation  Lab's  file 
server  was  accomplished  through  NPS's  NFS  (ethemet)  network.  However,  additional 
difficulties  were  encountered  while  loading  the  EADSIM  software  into  this  file  server. 
The  Sun  Systems  SPARCServer  computer  used  a  different  data  extract  format  than  that 
of  the  EADSIM  tape  provided  by  Teledyne  Brown  Engineering  (TBE).  Therefore,  the 
software  had  to  be  loaded  over  the  network  from  the  Visualization  Lab.  This  process  was 
very  slow  and  took  several  hours.  Other  problems  encountered  with  this  arrangement  was 
the  slow  operation  of  the  system  after  installation.  EADSIM  utilizes  large  data  files, 
which  do  not  lend  themselves  to  rapid  transmission  over  a  network.  Although  this  was 
a  temporary  solution,  it  was  not  a  very  satisfactory  solution. 

Successful  use  of  the  software  after  it  was  loaded  on  the  Sim  Lab's  computer  was 
precluded  by  corrupted  software.  The  scenarios  provided  were  "seen"  by  a  different 
version  of  the  EADSIM  software.  The  original  tape  was  run  through  a  computer  system 
at  TBE,  which  had  a  "Beta"  copy  of  the  Version  3.00  code  installed.  This  code  is 
designed  to  rewrite  the  older  scenarios  to  the  new  revised  format.  Unfortunately,  it  is  an 
irreversible  process,  and  the  original  scenario  software  load  was  lost.  A  "Beta"  copy  of 
the  Version  3.00  code  was  provided  by  TBE,  but  was  unworkable.  This  resulted  in  a 
delay  of  six  weeks  before  a  working  copy  of  EADSIM  was  installed  at  NPS.  Eventually, 
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a  new  (uncomipted)  copy  of  the  Version  2.07  software  was  successfully  installed  on  the 
new  hard  disk  in  the  SGI  Pov'zr  Series  380/VGX  of  the  Visualization  Lab. 

D.  SYSTEM  TRAINING  AND  SOFTWARE  MAINTENANCE 
1.  Training 

To  properly  maintain  EADSIM,  it  is  essential  that  trained  operators  be  available 
for  user  assistance.  System  training  may  be  contracted  through  the  SSDC  project  office. 
Since  formal  training  may  not  always  be  feasible,  a  comprehensive  set  of  instructions  is 
available  in  the  EADSIM  User's  Manual,  User's  Reference  Manual,  Methodology  Manual, 
and  Release  Notes.  The  manuals  provide  sufficient  detail  for  on  the  job  training.  Along 
with  the  documentation,  a  telephone  support  service  is  maintained  by  Teledyne  Brown 
Engineering. 

The  User’s  Manual  describes  data  preparation,  input  functions,  model  operations, 
and  output  functions.  It  has  a  companion  volume,  the  User's  Reference  Manual.  The 
User's  Reference  Manual  provides  specific  descriptions  of  model  functions  and  window 
operations  of  the  computer  program.  The  Methodology  Manual  discusses  the  modeling 
approach  taken  in  all  aspects  of  EADSIM.  Included  in  the  Methodology  Manual  is  the 
model  architecture,  processing  logic,  timing  and  sequencing,  and  key  equations. 

Hands  on  training  is  available  from  Teledyne  Brown  Engineering  and  CAS 
Incorporated.  Support  of  these  training  programs  is  conducted  by  SSDC.  The  courses 
are  normally  two  weeks  long,  however,  tailored  lesson  programs  can  be  arranged  to  meet 
the  user’s  needs.  A  one  week  EADSIM  user's  course  to  be  held  at  NPS  was  arranged  by 
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SSDC.  A  representative  from  CAS  Incorporated  presented  this  course  to  the  author  and 
another  NPS  student  in  April  1993. 

2.  Software  Updates 

All  EADSIM  software  is  government  owned.  Software  updates  are  conducted 
through  the  Change  Control  Board  (CCB)  and  the  Software  Configuration  Review  Board 
(SCRB).  The  CCB  is  a  government  group,  responsible  for  formal  processing  of  changes 
to  the  baseline  software.  The  SCRB  reviews  the  submission  of  Simulation  Change 
Requests  (SCR)  forwarded  by  the  users.  Should  a  user  develop  an  enhancement  to 
EADSIM,  or  discover  an  error  in  model  operation,  that  information  can  be  incorporated 
into  the  next  update  of  the  software.  An  SCR  is  filed  by  any  user  who  requests  a  change 
to  be  made  in  the  model.  The  SCR’s  are  reviewed  by  the  two  boards  (SCRB  and  CCB) 
for  incorporation  into  the  next  release  of  the  EADSIM  software.  Software  changes  and 
the  content  of  submitted  SCR's  are  reflected  in  the  Release  Notes.  [Ref  11] 

An  EADSIM  User's  Group  Meeting  is  held  several  times  per  year  to  discuss  model 
uses,  new  findings  and  applications,  and  to  resolve  any  problems  encountered  with  the 
model.  Major  software  updates  are  released  to  coincide  with  a  User's  Group  Meeting  to 
ensure  maximum  dissemination  of  new  material  contained  in  the  release.  The  author 
attended  the  last  conference  in  February  1993  at  TBE  in  Huntsville,  AL.  Refer  to 
Appendix  B  for  lessons  learned  from  the  last  User's  Group  Meeting.  The  next  User's 
Group  Meeting  is  scheduled  for  22  -  24  June  1993. 
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III.  EADSIM  MODELING  AND  SYSTEM  OPERATION 


A.  MODELING  CAPABILITIES 
1.  Forces  Modeled 

Both  friendly  and  hostile  forces  may  be  defined  in  the  EADSIM  as  a  variety  of 
platforms.  A  platform  contains  sensors,  weapons,  and  communications  equipment. 
Examples  of  platforms  are  air  breathers  (such  as  aircraft  and  cruise  missiles),  ballistic 
missiles,  surface  combatants,  air  bases,  surface-to-air  missile  (SAM)  batteries,  radar  sites, 
and  C^I  nodes.  The  platforms  and  associated  systems  are  selected  from  the  data  base  of 
the  EADSIM  library.  Their  characteristics  may  be  classified  up  to  the  secret  level.  In 
this  thesis,  however,  the  unclassified  data  base  was  used.  The  platform  and  system 
libraries  may  be  accessed  by  the  user  during  scenario  generation.  Scenario  Generation 
is  a  utility  within  EADSIM,  which  allows  the  creation  (or  modification)  of  a  scenario. 
During  scenario  generation,  the  platforms  are  selected  and  edited  if  necessary.  These 
platforms  are  then  added  to  the  battlefield  map  as  part  of  a  laydown  file.  All  of  these 
platforms  are  displayed  as  icons  within  the  graphical  environment  of  EADSIM.  Targets, 
also  represented  as  icons,  may  be  any  air  contact  or  surface  track.  The  operation  of  each 
platform  within  the  simulation  is  governed  by  rule  sets.  The  rule  sets  are  defined  in  the 
simulation  by  the  type  of  platform  which  is  modeled.  For  example,  fighter  aircraft  are 
modeled  using  the  fighter  rule  sets  to  perform  offensive  maneuvers  against  hostile  air 
contacts.  Rule  sets  will  be  discussed  in  greater  detail  later  in  this  chapter. 
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2.  Run-Time  Processes 


The  actual  modeling  of  the  interaction  between  the  different  platforms  is 
accomplished  within  EADSIM  by  four  parallel  nm-time  processes.  They  are  Detection, 
C^I,  Propagation,  and  Flight  Processing.  Each  of  these  processes  performs  specific  tasks 
within  the  simulation  to  enable  the  platforms  to  perform  their  various  missions, 
a.  Detection  Modeling 

The  Detection  process  determines  the  detections  made  by  each  platform. 
Target  detection  is  only  accomplished  using  the  free  space  radar  range  equation  within 
the  EADSIM  code.  Infrared  (IR)  detection  is  not  modeled  in  the  current  version  of 
EADSIM.  Factors  incorporated  into  the  model  include  radar  horizon  (4/3  Earth  model), 
transmitter  power,  receiver  signal  to  noise  ratio  (SNR),  radar  cross  section  (RCS), 
wavelength  (X,),  minimum  detectable  signal  (MDS),  and  antenna  gain.  These  factors  are 
normally  entered  in  terms  of  dBW,  rather  than  their  physical  values. 

The  Detection  Processor  module  is  a  deterministic  model  used  for  air  targets. 
The  range  determined  for  a  target  of  a  given  RCS  with  no  jamming  present.  If  jamming 
were  present,  then  a  reduced  detection  range  based  on  bum-through  would  result.  Radar 
range  can  be  displayed  as  a  detection  envelope  superimposed  over  the  scenario  map.  The 
radar  intervisibility  utility  develops  ihe  display,  accounting  for  terrain  and  altitude. 
Detection  of  ground  targets  is  a  statistical  model  with  a  random  number  draw.  The 
detections  are  then  sent  to  the  C^I  Processor.  [Ref  12] 
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b.  C^I  Modeling 

The  C^I  Processor  determines  individual  platform  actions,  resolves 
engagements,  processes  internal  command  and  track  messages,  exports  movement 
commands  to  the  Flight  Processor,  and  exports  search  information  back  to  the  Detection 
Processor.  The  C^I  Processor  conducts  all  internal  message  generation,  network  routing, 
network  loading  and  message  processing.  All  internal  communications  are  accomplished 
in  this  manner.  Target  tracking,  also  a  C^I  Processor  function,  is  implicit.  Tracking  is 
accomplished  via  truth  data,  which  is  the  actual  location  of  the  target  within  the 
simulation.  The  truth  data  for  a  track  is  continuously  maintained  by  the  C^I  Processesor. 
Once  a  target  is  deteced,  it  is  automatically  tracked  by  the  detecting  radar  system  based 
upon  truth  data  from  the  C^I  Processor.  Contact  is  lost  when  a  target  flies  out  of  range, 
below  the  horizon,  behind  a  land  mass,  or  is  shot  down.  Operator  delays  can  be 
programmed  into  a  simulation  by  increasing  reaction  time  within  the  model.  Target 
identification  is  also  accomplished  within  the  C^I  Processor  module.  Mode  4  IFF 
(identification  friend  or  foe)  can  be  modeled  with  a  simple  probabilistic  simulation.  A 
random  number  draw  is  made  when  a  track  is  initially  acquired.  The  draw  is  then 
compared  to  the  pre-set  IFF  value,  which  determines  if  the  target  is  positively  identified 
as  a  friendly  or  hostile.  The  identification  is  then  permanently  assigned  to  the  track.  This 
method  is  used  to  represent  IFF  system  reliability,  as  no  IFF  system  is  always  accurate. 
In  simple  scenarios,  IFF  may  be  omitted.  When  IFF  is  not  used,  truth  data  is  used  within 
the  scenario  to  prevent  fratricide  (Blue-on-Blue  engagements).  [Ref  12] 
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c.  Propagation  Modeling 

External  communications  are  governed  by  the  Propagation  Processor  of 
EADSIM.  The  Propagation  Process  is  used  to  determine  communications  connectivity. 
The  connectivity  of  radio  communications  is  governed  by  terrain,  power,  jamming,  and 
atmospherics.  In  addition,  antenna  orientation  may  effect  radio  communications  ’•  *hin 
the  simulation.  Connectivity  results  are  exported  to  the  C^I  processor.  Connectivity 
pairing  lines  may  be  viewed  during  scenario  generation.  These  lines  display  the 
communications  network  laydown.  Multiple  networks  may  be  displayed  to  show  the 
relationships  between  the  different  echelons  of  command.  Control  of  assets  is  also  shown 
in  this  maimer.  [Ref.  12] 

d.  Flight  Processing 

Actual  platform  movement  is  performed  by  the  Flight  Processing  module.  It 
moves  platforms  according  to  commands  received  from  the  C^I  Processor.  It  also  exports 
current  platform  positions,  as  truth  data,  to  all  of  the  other  processors.  Aircraft  flight 
within  EADSIM  uses  a  three  degree  of  freedom  flight  model.  This  model  is  not  an 
energy  model  and  does  not  accurately  reflect  the  physics  of  flight.  It  does,  however,  have 
the  capability  to  have  aircraft  perform  evasive  and  other  tactical  maneuvers  during  a 
simulation.  [Ref  12] 

B.  ENGAGEMENTS 

An  engagement  within  EADSIM  is  the  simulation  of  a  weapon  launch  against  a  target 
and  its  outcome.  However,  weapon  launch,  flyout,  and  terminal  effects  are  not  explicitly 
modeled.  Engagements  are  a  probabilistic  function  based  upon  the  default  value  for 
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probability  of  kill  (Pj.)  of  a  weapon  against  specific  targets.  This  can  be  modified  by 
the  user  during  Scenario  Generation.  A  killed  target  is  immediately  removed  from  the 
simulation  nm.  A  missed  target  will  continue  to  be  engaged  provided  that  it  still  meets 
target  criteria.  Most  targets  cannot  be  simulated  to  receive  damage.  The  exception  is  an 
air  base.  If  an  air  base  is  hit,  then  a  variety  of  restrictions  may  be  placed  on  its  operation. 
These  include  a  delay  in  the  aircraft  launch  schedule  to  simulate  shock,  damage,  and 
confused  (slower)  base  personnel. 

1.  Engagement  Pairings 

Engagement  pairings  are  graphically  displayed  in  the  playback  files.  Engagement 
pairing  lines  on  the  computer  display  indicate  an  engagement  against  a  target.  The  actual 
pairing  lines  change  color  as  an  engagement  takes  place.  During  the  vector  phase  of  a 
fighter  intercept,  a  purple  line  appears  when  the  fighter  is  positioning  itself  for  a  shot. 
The  line  changes  to  blue  as  acquisition  and  radar  lock  are  made.  A  white  line  indicates 
a  weapon  in  flight.  On  some  playback  files,  the  background  or  map  color  interferes  with 
the  visibility  of  pairing  lines.  If  this  happens,  the  color  editor  can  be  used  to  improve 
visibility  of  pairing  lines. 

2.  Weapon  Performance 

Weapon  performance  is  the  weak  link  in  EADSIM  operation.  A  major  limitation 
of  EADSIM  is  that  it  does  not  model  weapon  fly-out  for  anti-air  weapons.  As  such, 
weapon  performance  is  based  upon  factors  predetermined  by  EADSIM.  These  default 
parameters  can  be  changed  by  the  user  during  scenario  generation.  Flight  characteristics, 
such  as  maximum  and  minimum  range  may  be  set,  as  well  as  altitude  limits.  Speed,  radar 
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cross  section,  and  are  explicitly  modeled.  Their  values  are  assigned  to  the  weapon 
during  scenario  generation.  Flyout  of  air  to  ground  weapons  may  be  modeled  using  the 
captive  platform  rule  set.  This  allows  an  aircraft  to  cany  a  we^on,  which  is  modeled 
separately  as  an  airframe  with  a  warhead.  Antiship  missiles  are  frequently  modeled  in 
this  manner  and  can  be  given  waypoints  to  add  grin  order  that  they  may  be  viewed  during 
playback. 

Re-engagement  of  missed  targets  are  a  function  of  engageability.  Groimd  targets 
are  attacked  with  only  one  pass  of  the  attacking  aircraft.  If  the  aircraft  gets  within 
weapon  release  range,  then  a  hit  or  miss  is  a  function  of  a  draw.  Multiple  passes  may 
be  modeled  by  programming  additional  waypoints  back  to  the  target.  Engagements  of  air 
targets  continue  if  the  first  salvo  misses.  A  firing  unit  will  continue  to  shoot  provided 
that  there  is  ammunition  remaining,  the  target  is  still  within  range  and  it  meets  threat 
criteria. 

3.  Ammunition  and  Fuel  Expenditure 

Ammunition  expenditure  will  continue  provided  that  valid  targets  remain.  Should 
a  unit  run  out  of  ammunition,  it  will  begin  a  reload  cycle.  For  aircraft,  they  have  to  land 
at  home  base  to  rearm.  An  aircraft  will  also  return  to  base  should  it  reach  its  fuel 
reserves.  Ammunition  expenditure  is  controlled  by  the  salvo  rate  for  a  particular  launcher 
as  determined  during  Scenario  Generation.  The  number  of  "ready  service"  rounds  are  also 
pre-selected,  as  is  the  number  of  reloads.  Reload  time  is  also  predetermined  during 
Scenario  Generation.  During  the  execution  of  the  scenario,  the  salvo  rates  and  the  reload 
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cycles  are  timed  along  with  all  of  the  other  simulated  events.  A  launcher  will  not  reload 
until  all  of  its  ready  service  rounds  are  expended. 

Aircraft  expend  ammunition  in  accordance  to  their  respective  rule  set.  Fighters  and 
fighter  bombers  specifically  expend  air-to-air  missiles  as  a  function  of  air  combat. 
Fighters  will  continue  to  engage  hostile  aircraft  as  long  as  there  are  missiles  remaining. 
A  fighter  will  stay  with  its  wingman  if  it  has  weapons  available  and  has  an  intercept  in 
progress.  Attack  aircraft  and  bombers  expend  their  weapons  in  accordance  vvith  their 
flight  plan.  Wild  Weasel  aircraft  expend  anti-radiation  weapons  depending  on  the  number 
of  targets  of  opportunity.  Otherwise,  the  Wild  Weasel  aircraft  continue  to  orbit  awaiting 
to  be  queued  by  sensor  emissions. 

Fuel  consumption  by  aircraft  is  not  accurately  modeled  within  EADSIM.  The  fuel 
depletion  curve  is  linear,  regardless  of  aircraft  speed  and  altitude.  This  includes  aircraft 
operating  in  afterburner.  In  addition,  EADSIM  models  aircraft  idling  on  a  nmway  as  not 
burning  fuel.  In  most  cases,  an  aircraft  will  run  out  of  ordnance  before  it  runs  out  of  fuel. 

4.  Attrition  of  Forces 

The  forces  involved  in  a  scenario  conduct  offensive  and  defensive  actions  as 
programmed  during  Scenario  Generation.  A  ship  will  continue  to  defend  itself  until  it 
runs  out  of  weapons,  has  no  more  valid  targets,  or  it  is  sunk.  Attacking  aircraft  will 
follow  programmed  flight  paths  until  they  deliver  ordnance,  are  forced  to  dump  ordnance 
and  return  to  base,  or  are  shot  down.  Aircraft  remaining  in  a  SAM  envelope  too  long  will 
be  subject  to  multiple  engagements.  If  a  target  is  hit,  it  is  destroyed  and  removed  from 
the  simulation.  Most  scenario  nms  result  in  many  of  the  aircraft  being  destroyed. 
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5.  Re-Engagement  of  Survivors 

Survivors  of  an  engagement  are  automatically  re-engaged,  provided  they  are  still 
valid  targets.  This  gives  the  advantage  to  the  defender,  as  it  will  begin  to  engage  the 
target  at  its  maximum  weapon  range  and  will  continue  to  engage  as  the  target  closes.  In 
some  scenario  runs,  a  missile  system  may  take  as  many  as  four  shots  against  a  target. 

The  chances  of  the  target's  survival  against  four  missiles  are  slim.  For  example, 
if  the  Pj.  for  a  given  missile  against  a  particular  threat  is  0.7,  then  the  target  has  only  a 
0.3  probability  of  survival,  Pj,  after  one  shot.  It  can  be  shown  that  lethality  of  the  air 
defense  increases  with  the  number  of  weapons  that  can  be  fired.  Conversely,  survivability 
decreases  with  the  number  of  subsequent  engagements.  The  relationship  between  Pg  and 
Pf.  is;  Ps  =  (1  -  Pjc)".  Because  the  current  version  of  EADSIM  has  constant  single  shot 
probabilities  of  kill  (Pkss)  for  engagement,  simple  probability  theory  may  be  followed. 

C.  RULE  SETS 

The  operation  of  every  platform  is  accomplished  through  the  use  of  rule  sets.  These 
rule  sets  are  designed  for  different  types  of  units  so  that  they  can  follow  standard  tactics 
or  tactical  employment.  Rule  sets  consist  of  phases  of  operation,  message  processing  and 
generation  functions,  and  track  files.  An  example  of  an  operational  phase  is  engagement, 
when  a  missile  is  launched  at  the  target.  A  message  may  be  an  order  to  engage,  telling 
a  unit  to  fire  at  a  specific  track.  A  track  file  is  the  location  of  a  target  held  by  a 
particular  unit.  This  data  may  be  shared  over  existing  command  networks  within  the 
scenario.  The  remainder  of  this  Chapter  describes  the  rule  sets  used  extensively  in  this 
thesis. 
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1.  Surface-to-air  Missiles 


A  SAM  battery  may  be  assigned  the  Flexible  SAM  rule  set.  As  such,  it  may 
operate  autonomously  in  self  defense,  or  it  may  be  given  a  vital  asset  to  protect,  or  it  may 
be  assigned  as  a  subordinate  to  another  unit.  As  a  subordinate,  another  unit  may  direct 
the  firing  of  the  SAM  battery  against  a  threat.  A  SAM  battery  may  also  be  assigned  the 
SAM  Commander  rule  set.  The  SAM  Commander  may  also  have  other  batteries  under 
its  control  in  addition  to  its  organic  capability.  Self  defense  of  a  SAM  battery  is 
accomplished  with  the  use  of  threatening  and  critical  radii.  If  a  target  crosses  the 
threatening  radius  of  a  SAM  battery,  it  will  be  engaged  if  its  closest  point  of  approach 
falls  inside  the  critical  radius.  Contacts  inside  the  critical  radius  are  immediately 
scheduled  for  engagement.  For  SAM  batteries  protecting  a  vital  asset,  similar  distinctions 
are  made.  In  this  case,  the  SAM  engages  the  targets  threatening  the  vital  asset. 

The  Flexible  Commander  is  a  command  unit  given  authority  over  other 
engagement  platforms.  The  flexible  commander  may  have  a  number  of  assets  under  its 
control.  They  can  be  SAM  batteries  and  defensive  aircraft.  A  Flexible  Commander  may 
also  have  other  commanders  under  its  control.  Entire  echelons  of  a  command  structure 
may  be  modeled  in  this  manner. 

2.  Defensive  Aircraft 
a.  Fighter  Rule  Set 

Aircraft  operating  in  the  role  of  defensive  counter  air  are  assigned  the  Fighter 
rule  set.  Fighters  assigned  as  defensive  air  will  most  likely  be  designated  as  Combat  Air 
Patrol  (CAP).  The  fighter  and  its  wingman  are  given  a  CAP  station  and  waypoints  about 
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which  they  fly  a  racetrack  pattern.  The  racetrack  can  be  oriented  so  that  the  fighters' 
sensors  are  pointed  toward  the  threat  axis.  Fighters  can  be  ground  launched  from  an  air 
base  using  a  scripted  take-off  An  air  base  may  also  scramble  fighters  to  fill  CAP  stations 
which  have  had  their  fighters  vectored  off 

Fighters  designated  as  Interceptors  can  be  scripted  to  engage  a  specific  target 
already  in  flight.  The  danger  of  a  scripted  engagement  is  that  the  fighter  becomes  less 
useful  than  a  CAP  if  its  initial  target  is  shot  down  prematurely.  The  interceptor  fighter 
does  not  assume  an  active  CAP  role,  it  merely  loiters  until  a  target  of  opportunity  presents 
itself. 

b.  Fighter  Control 

Fighter  control  can  be  modeled  with  two  methods.  One  method  of  control  is 
the  Ground  Controlled  Interceptor  (GCI)  via  the  Flexible  Commander  rule  set.  The  GCI 
is  controlled  by  a  ground  station  that  also  has  a  surveillance  radar.  The  surveillance  radar 
has  better  range  than  a  fighter's  sensors.  The  second  fighter  control  method  is  the 
AW  ACS  (Airborne  Early  Warning  and  Control  System)  rule  set  The  AW  ACS  has  the 
advantage  of  being  at  altitude  and  is  not  horizon  limited  as  is  the  ground  radar.  Also 
modeled  in  EADSIM  are  AW  ACS  with  the  Joint  Tactical  Information  Distribution  System 
(JTIDS).  With  JTIDS,  the  AW  ACS  can  rapidly  send  orders  to  fighters  under  its  control 
without  the  use  of  voice  commands.  This  results  in  an  improved  reaction  time  for  the 
AWACS  controlled  fighters,  possibly  engaging  their  target,  or  targets,  before  they  are 
counter-detected. 
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3.  Offensive  Aircraft 


Offensive  aircraft  follow  rule  sets  strictly  according  to  their  mission.  EADSIM  is 
principally  oriented  toward  defensive  measures,  therefore,  the  offensive  rule  sets  tend  to 
have  lower  fidelity  as  compared  to  the  defensive  rule  sets  These  rule  sets  are  designed 
to  perform  mainly  scripted  tasks  and  do  not  model  command  and  control  functions, 

a.  Bomber  Rule  Set 

The  most  basic  of  the  offensive  aircraft  follow  the  Bomber  rule  set.  Bombers 
are  strictly  air  to  surface  and  fly  a  pre-planned  flight  path  to  the  ground  target.  If 
engaged,  bombers  will  perform  evasive  maneuvers,  employ  countermeasures,  and  resume 
their  mission  if  the  engagement  is  survived.  The  bomber  rule  set  does  not  simulate  a  pop 
up  or  loft  deliver  of  gravity  bombs.  This  may  be  simulated  by  scripting  the  pop  up 
maneuver  in  the  bomber  flight  path.  The  model  will  drop  only  one  bomb  on  a  target 
during  a  simulated  bombing  run.  This  is  an  EADSIM  limitation.  To  emulate  a  multiple 
bomb  release,  the  of  the  bomb  being  delivered  is  raised.  This  will  have  the  same 
effect  within  the  scenario  as  a  multiple  bomb  release.  Bombers  cannot  be  assigned  as 
wingmen,  but  can  fly  in  formation  with  a  designated  flight  leader. 

b.  Fighter-Bomber  Rule  Set 

The  Fighter-Bomber  rule  set  is  designed  to  simulate  attack  aircraft  that  have 
a  self  defense  capability.  They  follow  the  bomber  rule  set  while  on  a  ground  attack 
mission.  If  engaged  by  hostile  fighters,  fighter-bombers  can  perform  a  react  to  engage 
maneuver.  This  may  include  jettisoning  of  weapons  (a  pre-programmed  option)  and  a 
turn  to  engage  the  attacker.  The  aircraft  return  to  their  flight  path  after  the  engagement 
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is  resolved,  or  return  to  base  if  all  air-to-surface  weapons  were  jettisoned.  The  fighter- 
bomber  may  not  be  assigned  as  a  wingman  for  combat  support,  but  may  also  fly  in 
formation  with  a  flight  leader. 

c.  Escort  Fighter  Rule  Set 

Escort  Fighters  are  fully  reactive  in  air  combat.  They  may  be  assigned  as 
wingmen  to  bombers  and  fighter-bombers.  This  allows  them  to  be  employed  as  protection 
for  the  aircraft  performing  an  attack  mission.  Phases  of  operation  are  similar  to  those  of 
the  fighter  rule  set  without  a  target  selection  phase.  The  escort  fighter  becomes  active  in 
air  combat  if  it,  or  the  aircraft  it  is  assigned  to  protect,  is  attacked.  If  such  an  attack 
occurs,  the  escort  fighter  performs  the  "react  to  engagement  maneuvers"  of  a  fighter- 
bomber. 

d.  Fighter  Sweep  Rule  Set 

Fighter  sweeps  are  accomplished  with  the  "Sweeper"  rule  set.  It  follows  logic 
identical  to  the  fighter  rule  set,  except  that  there  is  no  message  processing  capability.  As 
a  result,  the  sweeper  cannot  receive  AW  ACS  or  GCI  radar  data.  This  can  result  in 
multiple  fighter  sweeps  attacking  the  same  target.  Sweepers  also  cannot  be  assigned 
wingmen,  thus  they  only  operate  in  single  flights.  Such  operation  may  cause  a  bias  in 
scenario  results.  Experienced  EADSIM  users  have  discovered  that  smaller  flights  often 
outperform  larger  flights  of  aircraft.  This  problem  is  inherent  to  the  logic  of  the  program, 
which  allows  small  formations  of  aircraft  to  fly  more  aggressively  than  large  formations. 
Thus,  the  use  of  the  Sweeper  rule  set  is  not  recommended.  [Ref.  12] 
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e.  Wild  Weasel  Rule  Set 

The  Wild  Weasel  rule  set  offers  the  highest  fidelity  of  any  offensive  aircraft. 
The  rule  set  is  semi-scripted,  in  that  the  Wild  Weasel  is  given  a  potential  list  of  targets, 
and  it  dynamically  selects  a  target  if  its  emitter  is  detected  on  the  battlefield.  If  the 
received  signal  is  above  the  launch  threshold,  it  closes  to  weapon  release  range.  If 
already  in  range,  the  Wild  Weasel  performs  "avoid  lock"  and  triangulation  maneuvers. 

An  anti-radiation  weapon  is  then  fired  if  launch  conditions  are  met.  Following  launch, 
the  aircraft  returns  to  its  programmed  flight  path  or  operating  station.  A  Wild  Weasel  will 
continue  to  attack  ground  radars  on  its  target  list  provided  it  receives  emissions  and  it  has 
anti-radiation  weapons  remaining. 

If  attacked  by  hostile  fighters,  the  Wild  Weasel  performs  maneuvers  identical 
to  those  of  the  fighter-bomber.  The  Wild  Weasel  aircraft  also  maneuvers  aggressively  in 
reaction  to  lock-on  if  engaged  by  a  SAM.  This  improves  the  survivability  of  the  aircraft 
and  closely  models  real  world  maneuvers.  Operator  modifications  to  the  Wild  Weasel 
rule  set  may  be  selected  from  a  menu  of  options.  These  are  designed  to  improve  the 
fidelity  of  employment  of  SEAD  aircraft.  Thresholds  can  be  varied  to  reouire  the  wild 
weasel  to  be  painted  more  (or  fewer)  times  to  react.  In  addition,  reaction  maneuvers  can 
also  be  modified. 

4.  Rule  Set  Modification 

Rule  sets  can  be  modified  to  achieve  higher  levels  of  fidelity.  By  assigning 
multiple  rule  sets,  a  platform  can  be  given  enhanced  capabilities.  One  such  example  is 
to  designate  a  CAP  flight  leader  as  a  flexible  commander  as  well.  This  will  give  it  more 
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autonomy  in  employing  its  wingman.  Other  rule  set  modifications  can  be  made  at  the 
source  code  level.  The  Lockheed  Corporation  has  created  an  improved  fighter-bomber 
rule  set  (called  Ghostrider)  to  emulate  a  proposed  capability  of  the  A/F-X.  With  this 
model,  the  aircraft  performs  equally  well  in  either  fighter  or  attack  mode.  It  may  also 
switch  from  one  mode  to  another  as  the  situation  within  the  scenario  changes.  Source 
code  modifications  are  beyond  the  scope  of  this  project  and  will  not  be  attempted. 

5.  Areas  of  Interest 

For  any  scenario,  a  certain  readiness  posture  is  implicitly  modeled.  EADSIM 
assumes  that  "hot  war"  conditions  exist.  Should  a  target  be  determined  to  be  a  threat,  it 
will  be  engaged.  Rules  of  engagement  (ROE)  may  be  explicitly  modeled  with  areas  of 
interest  (AOI).  The  AOI  rule  set  models  missile  engagement  zones  (MEZ)  and  fighter 
engagement  zones  (FEZ).  Friendly  aircraft  can  be  given  safety  routes  through  an  AOI  to 
prevent  fratricide. 
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IV,  SCENARIOS  DEVELOPED  FOR  NPS 


A.  SCENARIO  REQUIREMENTS 
1.  Modeling  of  Navy  Assets 

EADSIM  has  only  a  limited  selection  of  warships  and  naval  aircraft  pre-built  in 
the  platform  and  system  libraries.  This  is  mainly  a  result  of  EADSIM's  origin  as  an  Army 
project.  Much  of  the  modeling  of  the  air  combat  represented  by  EADSIM  was  developed 
with  the  aid  of  Air  Force  pilots.  Thus,  there  has  been  less  Navy  support  for  the 
simulation  as  compared  to  the  other  services.  Although  not  originally  designed  to  do  so, 
surface  ships  and  carrier  based  aircraft  can  be  represented  within  the  simulation.  This  is 
enabled  by  modifying  the  existing  rule  sets  previously  discussed  in  Chapter  III.  With 
manipulation  of  the  rule  sets,  many  naval  units  can  be  created  with  an  acceptable  degree 
of  fidelity. 

The  simulation  of  naval  units  can  be  accomplished  by  one  of  two  methods.  The 
first,  and  simplest,  method  is  to  modify  an  existing  system.  The  specifications  of  systems 
in  the  EADSIM  library  may  be  modified  to  reflect  those  desired  by  the  user.  Care  must 
be  taken  by  the  user  to  ensure  that  "generic”  numbers  are  used,  so  as  not  to  risk 
accidental  disclosure  of  classified  data.  A  common  practice  is  to  use  specifications  given 
in  Jane's  or  other  such  open  sources  of  information.  In  addition,  the  user  should  give  the 
"new"  unit  a  name  other  than  the  default  designation.  This  will  prevent  overwriting  the 
default  values  for  the  original  system. 
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The  second  manner  in  which  to  create  a  unit  is  to  build  the  systems  from  scratch. 
This  is  done  within  the  existing  rule  sets  of  EADSIM.  For  example,  the  F/A-18,  which 
is  not  modeled  in  EADSIM,  may  be  represented  by  following  the  fighter-bomber  rule  set 
in  the  unclassified  database.  All  the  aircraft  characteristics  are  entered  into  EADSIM 
during  scenario  generation.  Again  the  specifications  of  the  actual  system  are  represented 
within  the  model,  as  programmed  by  the  user. 

B.  THE  AAW  SIMULATION  FOR  USE  IN  AE3705 
1.  Naval  Forces  Operating  in  Littoral  Waters 

A  new  mission  statement  for  the  United  States  Navy  describes  Naval  and  Marine 
Corps  units  "operating  forward  from  the  sea  [Ref  5]."  As  such.  Naval  conflicts  in  the 
future  are  less  likely  to  be  conducted  on  the  open  ocean  and  more  likely  to  occur  in 
coastal  or  littoral  waters.  The  anti-air  warfare  simulation  modeled  in  this  thesis  consists 
of  naval  forces  operating  in  littoral  waters.  Three  scenerios  are  developed.  One  scenario 
investigates  the  AAW  self-defense  capability  of  a  ship  operating  alone  in  Eastern 
Mediterranean  waters.  A  second  scenario  has  two  ships  operating  together  against  the 
same  threat.  Two  runs  of  the  two  ship  scenarios  are  to  be  conducted  in  the  lab,  to 
explore  the  EADSIM  modeling  of  command  networks.  One  run  is  conducted  with  the 
ships  operating  autonomously.  A  second  run  has  the  ships  under  a  centralized  command. 
In  the  latter  case,  one  ship  directs  the  engagement  of  hostile  air  contacts  for  both  vessels. 
The  final  AAW  scenario  concerns  the  defense  of  a  vital  asset.  The  ships  from  the 
previous  scenario  are  assigned  to  protect  an  aircraft  carrier  against  the  same  air  threat. 
A  comparison  of  centralized  control  (carrier  vs.  cruiser)  is  studied  with  this  scenario. 
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Because  the  primary  area  of  interest  is  surface  ship  AAW,  the  carrier  air  wing  is 
purposely  left  out  of  the  scenario.  Thus,  combat  air  patrol  (CAP)  and  other  fighters  are 
not  available. 

2.  The  Threat 

The  threats  selected  are  from  a  hostile  Middle  Eastern  nation.  They  consist  of 
"Red"  marmed  aircraft  and  anti-ship  cruise  missiles  (ASCM's).  The  ASCM  threat  are  both 
shore  laimched  and  air  launched.  The  shore  launched  anti-ship  missiles  are  an 
approximation  of  the  Silkworm  missile.  The  Silkworm  is  itself  a  modification  of  a  first 
generation  ASCM,  the  SS-2-N  Styx.  The  Styx  was  the  first  weapon  of  its  type  to  be 
successfully  used  in  combat.  It  is  credited  with  the  sinking  of  the  Israeli  destroyer  Eliath 
during  the  1967  Six  Day  War.  Although  Styx  is  approaching  obsolescence,  its  Chinese 
built  successor  has  seen  much  use  in  the  Persian  Gulf  Wars  of  the  past  decade.  Because 
of  the  open  source  data  available  on  Silkworm  and  because  it  is  a  likely  threat,  it  was 
selected  for  this  scenario.  Modeling  of  a  shore  launched  ASCM  uses  the  TEL  icon.  The 
weapon  on  the  TEL  is  given  the  flight  profile  of  a  typical  ASCM. 

Air  launched  versions  of  Silkworm  can  be  carried  by  the  Tu-16  Badger  bomber. 
The  modeling  of  an  air  launched  missile  is  more  complex  because  it  must  be  modeled  as 
a  captive  platform.  This  is  accomplished  by  creating  an  airframe  carrying  a  separate 
warhead.  By  doing  so,  the  hybrid  weapon  can  be  given  its  own  flight  path  when  fired 
from  its  launch  platform.  The  addition  of  the  long  range  air  threat  is  designed  to  create 
multiple  threat  axes  and  to  possibly  saturate  the  defending  ship's  air  defense. 
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Other  attacking  aircraft  are  the  MiG-23  Flogger,  which  follow  the  fighter  bomber  rule 
set.  They  are  armed  with  gravity  bombs  and  standoff  weapons.  The  standoff  weapons 
of  a  fighter-bomber  are  not  modeled  as  a  c^tured  platform.  As  such,  there  is  no  specific 
weapon  flyout,  only  a  P,,  against  the  target.  The  Floggers  are  programmed  to  fly  varying 
low  level  ingress  routes  to  their  naval  targets.  As  with  Silkworm,  the  MiG-23  is  an 
aircraft  common  to  many  potential  adversaries  and  was  thus  selected  for  this  project.  To 
further  complicate  air  defense  measures,  the  attacking  Red  forces  are  scripted  to  conduct 
a  coordinated  attack  against  the  Blue  units. 

3.  Ships  Operating  Autonomously 

The  first  group  of  scenario  runs  are  concerned  with  ships  operating  alone.  The 
surface  ships  modeled  in  the  AAW  scenarios  are  "Blue"  units.  Specifically,  they  are  an 
Aegis  cruiser  and  a  Spruance  Class  Destroyer  operating  in  the  Eastern  Mediterranean. 
The  cruiser  is  equipped  with  the  AN/SPY-1  phased  array  radar  and  the  SM-2  naval  SAM. 
These  systems  are  modified  from  the  elements  available  within  EADSIM.  Unclassified 
parameters  of  the  SPY-1  radar  replace  those  of  the  Patriot  AN/MPQ-53  phased  array. 
This  sensor  is  then  installed  on  the  Aegis  cruiser  icon  within  the  scenario.  The  SM-2 
modeled  is  a  modification  of  the  Standard  missile  found  in  the  simulation  library.  The 
destroyer  is  equipped  with  the  NATO  Sea  Sparrow  missile  system.  This  weapon  system 
is  also  an  adaptation  of  those  existing  within  EADSIM.  The  modifications  are  conducted 
to  more  closely  model  the  missile  specifications  as  found  in  Jane's  and  other  unclassified 
sources. 
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4.  Ships  Operating  Together 

In  the  second  set  of  scenario  runs,  the  two  units  mentioned  above  operate  together. 
One  run  has  the  ships  operating  under  independent  command.  The  second  run  has  the 
ships  operating  imder  a  combined  command  structure.  This  allows  the  simulation  of  a 
real  world  command  and  control  structure,  such  as  the  Naval  Tactical  Data  Syst'^m 
(NTDS).  It  also  should  eliminate  dual  engagement  of  a  target  by  both  ships  and  ensure 
the  protection  of  destroyer  by  the  area  defense  capability  of  the  cruiser. 

5.  Protection  of  a  High  Value  Unit 

The  final  version  of  the  of  scenario  concerns  the  protection  of  a  vital  asset.  In  this 
case,  the  high  value  unit  is  an  aircraft  carrier  (CV).  The  two  ships,  as  modeled  above, 
are  positioned  to  protect  the  CV.  The  destroyer,  with  the  short  range  AAW  weapons  is 
positioned  close  to  the  CV  and  the  cruiser,  with  its  longer  range  missiles,  is  positioned 
up  the  threat  axis.  Two  versions  of  this  scenario  are  to  be  conducted,  one  with  command 
and  control  on  the  carrier,  the  other  with  C^I  on  the  cruiser.  The  purpose  of  this  exercise 
is  to  determine  if  the  command  authority  has  any  effect  on  the  scenario  outcome.  In  both 
cases,  the  CV  is  defined  as  a  vital  asset. 

6.  Other  Variations 

The  scenarios  are  designed  to  determine  any  advantages  of  an  area  defense  system, 
such  as  Aegis  over  the  point  defense  systems  of  a  less  capable  surface  combatant.  In 
addition,  ship  positioning  against  a  threat  can  also  be  studied.  The  student  in  AES  705 
may  want  to  vary  weapon  parameters  such  as  range  and  probability  of  kill  Furthermore, 
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the  command  networks  may  be  analyzed  by  the  student.  The  C^I  functions  of  a  tactical 
data  link  are  critical  to  fleet  operations. 

C.  THE  AIRCRAFT  STRIKE  SIMULATION  FOR  USE  IN  AE3251 
1.  Aircraft  Strike  Against  a  Defended  Target 

The  air  assets  conducting  the  strike  are  Blue.  The  attack  aircraft  is  the  F/A-18 
Hornet  and  the  jamming  aircraft  is  the  EA-6B  Prowler,  neither  of  which  are  in  the 
standard  EADSIM  library.  The  F/A-18  is  created  using  the  Fighter  Bomber  rule  set,  and 
the  EA-6B  is  created  using  the  Wild  Weasel  rule  set  and  other  systems  within  EADSIM. 
A-6E  Intruders  may  also  be  modeled  with  the  Wild  Weasel  rule  set  so  that  they  may 
carry  anti-radiation  missiles  (ARM's).  The  Blue  fighter  aircraft  covering  the  strike 
package  in  one  phase  of  this  scenario  is  the  F-14  Tomcat.  The  F-14  is  contained  in  the 
EADSIM  library. 

The  ground  units  that  are  being  attacked  are  generic  airfields  near  Beirut.  They 
are  defended  by  a  variety  of  Red  SAM's  and  early  warning  radar.  The  basis  of  this 
scenario  was  provided  by  Teledyne  Brown  Engineering.  It  has  been  used  by  TBE  in  the 
demonstration  of  EADSIM  to  potential  users.  The  original  scenario  uses  Air  Force  units 
with  AW  ACS  support  against  a  similar  air  defense  arount  Baghdad. 

The  defensive  counter  air  consists  of  Red  MiG-29  Fulcrums  and  Red  MiG-23 
Foxbat  fighters.  The  defensive  aircraft  are  placed  on  CAP  stations  above  their  air  bases. 
They  may  be  directed  by  GCI  stations,  but  do  they  not  have  airborne  early  warning 
support.  Additional  ground  launched  interceptors  are  left  out  of  the  scenario  for 
simplicity. 
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2.  Unprotected  Raid 

The  simulation  of  strike  aircraft  attacking  defended  ground  targets  is  accomplished 
in  five  phases.  The  first  phase  has  attack  aircraft  conducting  a  strike  against  enemy 
airfields  defended  by  surface-to-air  missiles  (SAM's).  Flights  of  F/A-18  aircraft  attack 
two  airfields  heavily  defended  by  SAM's.  The  strike  aircraft  are  unprotected  and  armed 
with  only  gravity  bombs  This  is  a  worst  case  scenario.  It  will  show  that  an  unprotected 
attack  against  an  integrated  air  defense  network  is  difficult. 

3.  Adding  Stand-Off  Weapons 

A  second  phase  of  this  particular  scenario  gives  the  attackers  stand-off  weapons, 
in  the  hope  to  avoid  the  air  defense.  The  Maverick  missiles  should  minimize  the  strike's 
exposure  to  the  hostile  SAM  envelopes. 

4.  Suppression  of  Enemy  Air  Defense 

The  third  phase  further  improves  the  survivability  of  the  strike  aircraft  by  arming 
some  of  the  them  with  anti-radiation  missiles.  In  this  version  of  the  strike  scenario,  the 
attack  aircraft  may  still  be  exposed  to  the  Defending  SAM  batteries.  To  protect  the  strike 
package,  stand-off  jamming  and  the  Wild  Weasel  rule  set  are  used  to  degrade  radar 
sensors  and  actively  employ  anti-radiation  missiles  against  the  SAM  sites.  As  a  result, 
the  aircraft  attacking  the  ground  targets  in  this  third  phase,  are  less  susceptible  to  ground 
fire.  The  modeling  of  countermeasures  against  anti-air  weapons  has  the  effect  of  "anti¬ 
weapons".  EADSIM  lowers  the  of  the  weapon  in  the  presence  of  countermeasures. 
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5.  Defensive  Counter  Air 


Defensive  counter  air  opposes  the  strike  in  the  fourth  phase.  The  scenario  now 
has  CAP  and  ground  launched  interceptors  available  to  the  defender.  They  are  MiG-29 
Fulcrum  and  F-1  Mirage  fighters,  which  are  comparable  to  the  F/A-18  in  air-to-air 
combat.  The  MiG  and  Mirage  fighters  will  have  the  support  of  ground  control  intercept 
(GCI)  radar  and  have  the  advantage  of  not  carrying  the  extra  weight  of  ordnance  as  do 
their  opponents.  The  F/A-18's  will  be  following  the  fighter-bomber  rule  set  and  may 
jettison  their  ordnance  to  engage  the  hostile  fighters.  Fighter  aircraft  on  combat  air  patrol 
(CAP)  stations  are  positioned  to  defend  their  base.  They  can  be  directed  by  ground  radar, 
or  rely  on  their  own  sensors.  The  defensive  counter  aircraft  follow  the  Ground  Controlled 
Interceptor  (GCI)  fighter  rule  set. 

6.  Escort  Fighters 

To  defend  the  attack  aircraft,  a  fighter  escort  is  incorporated  into  the  fifth  phase. 
The  escort  is  the  F-1 4A  Tomcat  and  will  accompany  the  strike  package  along  the  mission 
route.  The  escorts  can  be  modeled  with  the  Escort  Fighter  rule  set,  or  conduct  fighter 
sweeps  using  the  Sweeper  rule  set.  In  either  case,  the  escorts  engage  the  defending  CAP, 
allowing  the  strike  aircraft  to  perform  their  mission. 

Because  of  the  capability  of  EADSIM,  a  far  more  complex  air  battle  may  be 
modeled.  The  use  of  early  warning  aircraft,  such  as  AWACS,  can  greatly  improve  the 
effectiveness  of  one  side's  fighters.  The  defender  can  also  be  given  an  advantage  by 
allowing  numerous  ground  sensors  and  a  more  sophisticated  C^  network.  Another 
EADSIM  limitation  is  encoimtered  in  thes  ir-to-air  engagement  scenarios.  There  is  not 
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an  exact  modeling  of  the  AWG-9  or  other  multiple  engagement  radar  system. 
Simultaneous  engagement  with  multiple  Phoenix,  or  other  extended  range  air-to-air 
missiles  AAM's,  is  not  modeled  within  EADSIM. 

7.  Other  Variations 

These  Strike  Warfare  scenarios  are  specifically  designed  for  AE3251.  They  are 
created  to  show  the  effect  of  different  measures  and  countermeasures  that  may  be 
employed  to  increase  the  survivability  of  a  strike  aircraft.  A  parameter  students  may 
investigate  is  the  reduction  of  radar  cross  section  (RCS).  By  reducing  RCS,  students  may 
see  a  direct  correlation  with  increased  survivability. 

D.  SCENARIO  GUIDE  AND  USER’S  GUIDE 

An  EADSIM  Scenario  Guide  (Appendix  C)  and  User's  Guide  (Appendix  D)  have  been 
developed  for  laboratory  use.  Should  EADSIM  be  programmed  into  either  AE3705  "Air 
Defense  Lethality"  or  AE3251  "Aircraft  Combat  Survivability,"  the  guides  will  assist  the 
uninitiated  student  through  a  scenario.  The  Scenario  Guide  contains  the  descriptions  of 
this  chapter,  the  available  assets  of  both  Red  and  Blue,  and  their  employment  within  the 
scenario.  The  scenarios  are  scripted  so  that  students  need  not  create  their  own. 

Because  of  the  complexity  of  EADSIM  and  the  UNIX  operating  system  (most  students 
cannot  be  expected  to  have  sufficient  UNIX  experience),  the  User's  Guided  is  a 
programmed  text  that  takes  the  student  through  the  scenario  playback  function  step  by 
step.  This  will  allow  a  student  to  view  a  playback  file  with  little  system  experience. 
Should  a  student  desire  more  knowledge  of  EADSIM,  the  reference  manuals  are  available 
in  the  laboratory. 
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V.  SCENARIO  EXECUTION 

A.  RUN-TIME  SIMULATION 

The  actual  execution  of  an  EADSIM  scenario  is  conducted  in  "real  time"  with  respect 
to  the  platforms  involved.  The  Scenario  Execution  routine  starts  the  four  run-time  models 
of  Detection,  C^I,  Propagation,  and  Flight  Processing  that  were  discussed  in  Chapter  III. 
The  four  run-time  models  are  separated  using  the  multiple  processor  architecture  of  the 
Visualization  Lab's  Silicon  Graphics  380/VGX.  Each  is  model  is  processed  on  its  own 
CPU  within  the  computer.  This  division  of  the  processing  is  similar  to  dividing  the 
processes  over  several  desktop  workstations.  By  using  the  power  and  memory  of  the 
380/VGX,  the  user  is  able  to  perform  several  scenario  runs  in  the  time  that  it  would  take 
for  a  single  run  on  a  lesser  machine.  The  Scenario  Execution  routine  also  determines  if 
the  scenario  run  had  a  successful  start.  It  allows  for  final  scenario  editing,  specification 
of  output  files,  and  setting  of  Monte  Carlo  options. 

B.  MONTE  CARLO  RUNS 

The  Monte  Carlo  options  are  accessed  within  the  program  from  the  Scenario 
Execution  routine.  Monte  Carlo  runs  may  be  conducted  in  two  ways.  In  the  first,  the 
user  selects  the  random  number  seed  for  each  scenario  run.  The  second  method  allows 
the  computer  to  select  the  next  random  number  for  each  consecutive  run.  EADSIM 
executes  the  scenario  for  the  specified  number  of  Monte  Carlo  nms  selected  by  the  user. 
Each  run  is  saved  in  its  own  file,  designated  by  a  number  tacked  on  to  the  file  name.  The 
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results  of  each  Monte  Carlo  run  are  different,  although  at  first  appearance  they  may  look 
similar. 

In  the  Monte  Carlo  method,  a  different  random  number  seed  may  be  used  for  each 
run.  A  UNIX  workstation  with  software  programmed  in  C  can  produce  over  two  billion 
random  numbers.  Specifically,  2  *  10*'  -  1  numbers  can  be  generated  by  the  following 
subroutine  writtei;  in  C: 

max  =  pow(2.0,  31.0)-1.0; 
scanf("%d",  &seed); 
srandom(seed); 
r  =  random()/max; 

The  random  number  generator  may  be  modified  so  that  it  can  produce  multiple  random 
numbers  for  many  Monte  Carlo  runs  of  a  large  scenario 

C.  COMPUTER  GENERATED  REPORTS 

The  Post  Processing  routine  of  EADSIM  is  the  primary  method  of  generating 
statistical  reports  concerning  the  results  of  a  scenario  run.  The  user  can  define  the  reports 
prior  to  scenario  nm  or  during  Scenario  Generation.  All  platform  activity  in  a  scenario 
run  may  be  reported,  or  specific  actions  for  specific  platforms  can  be  reported.  These 
reports  are  formatted  as  text  files  that  can  be  printed  or  downloaded  into  an  off-line 
application  such  as  a  spreadsheet.  Post  Processing  occurs  after  the  run-time  processes 
have  been  executed.  There  are  two  basic  report  types,  history  and  time  interval.  A 
history  report  gives  the  data  in  the  order  that  it  occurred.  A  time  interval  report  gives 
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data  in  the  same  order  as  the  history  report,  but  only  during  the  specific  time  interval  as 
set  by  the  user.  [Ref  13:p.  9-1] 

1.  Detection  Post  Processing  Reports 

The  Detection  Statistics  reports  provide  a  record  of  detections  made  during  a 
scenario  run.  A  variety  of  specifications  may  be  selected  by  the  user.  These  include 
Total  Detections,  First  Detections,  Detected  By,  Detected  From,  and  Time  Interval  [Ref 
13;p.  9-1].  First  Detections  can  be  further  optimized  to  give  those  of  a  particular  sensor 
or  platform  and  may  also  give  the  range,  altitude,  azimuth  and  elevation  angle  of  the 
detection  [Ref.  13:p.  9-1].  These  options  allow  the  user  to  analyze  the  performance  of 
a  particular  sensor  or  platform. 

2.  Communications  Post  Processing  Reports 

The  Communications  statistics  reports  provide  a  record  of  message  traffic  sent 
over  the  command  networks  of  an  EADSIM  scenario  [Ref  13:p.  9-1].  They  can  be  used 
to  report  on  all  of  the  networks  of  a  scenario,  or  only  those  networks  selected  by  the  user. 
The  user  may  use  the  reports  to  analyze  the  effectiveness  of  the  communications  networks 
of  the  scenario. 

3.  Engagement  Post  Processor 

The  Engagement  statistics  report  provides  a  record  of  engagements  taken  against 
one  platform  by  another.  The  user  may  select  all  engagement  actions,  or  specific 
engagement  actions  such  as  air-to-air  engagements.  The  user  may  also  select  engagement 
actions  performed  by  specific  platforms.  This  will  allow  the  user  to  isolate  the 
performance  of  that  particular  platform.  [Ref  13;p.  9-1] 
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E.  DATA 


The  data  for  the  two  scenarios  run  as  part  of  this  project  are  contained  in  the  Post 
Processing  reports.  The  reports  are  generated  at  the  time  of  the  scenario  run  and  stored 
by  the  computer.  They  can  be  printed  off-line  for  future  analysis,  or  downloaded  into  an 
off-line  application.  Each  report  can  run  several  hundred  pages  and  contains  a  description 
of  scenario  events.  The  same  data  is  used  in  the  playback  file.  Refer  to  Appendix  E  for 
an  excerpt  from  the  Post  Processing  report  of  the  Naval  AAW  scenario. 

F.  SCENARIO  PLAYBACK 

One  of  the  easiest  ways  to  observe  the  results  of  a  particular  scenario  run  is  to  simply 
view  the  scenario  playback  file.  EADSIM  provides  a  Playback  routine  that  is  selected 
through  the  graphical  user  interface.  A  playback  file  is  based  upon  truth  data  provided 
by  the  run-time  processes.  A  playback  shows  a  visual  representation  of  the  simulation 
superimposed  over  the  battlefield  map.  The  individual  icons  of  the  platforms  move  in 
accordance  with  their  operation  within  the  scenario.  By  observing  the  playback,  the  user 
can  observe  the  timing  of  certain  events,  such  as  initial  detection,  when  a  ship  or  missile 
battery  begins  to  fire,  or  when  a  fighter  begins  an  intercept.  The  playback  file  displays 
the  engagement  pairing  lines.  These  lines  indicate  which  of  the  firing  units  are  engaging 
specific  targets.  If  a  target  is  destroyed,  then  a  symbol  is  left  on  the  map  to  indicate 
where  it  was  destroyed.  A  circle  with  a  slash  through  it  indicates  a  downed  aircraft,  a 
square  with  a  slash  through  it  indicates  a  destroyed  surface  target,  or  ship.  Missiles  that 
are  destroyed  are  not  indicated  by  a  symbol. 
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VI.  EFFECT  OF  CHANGING  PROBABILITY  OF  KILL 


A.  THE  EADSIM  WEAPON  MODEL 

1.  Probability  of  Kill 

Because  weapon  modeling  is  considered  to  be  a  weakness  of  EADSIM,  the  author  has 
investigated  a  specific  aspect  of  the  weapon  model,  the  probability  of  kill  (Pr)  for  surface-to- 
air  missiles.  The  Pk  values  found  in  the  EADSIM  library  are  default  values  for  the  particular 
weapon  being  modeled.  The  P^  of  a  weapon  in  EADSIM  is  in  reality  a  single  shot 
probability  of  kill,  P^ss  Because  the  engagement  function  of  an  EADSIM  scenario  has  been 
reduced  to  a  kill  or  survive  determination,  the  term  P^  is  used. 

2.  User  Selectable  P^ 

Some  weapons  in  the  model  may  not  have  a  default  Pj.  intentionally,  or  the  user  may 
desire  to  change  a  default  value.  Should  the  user  create  a  new  weapon  within  the  model,  then 
a  user  selected  default  P^  would  also  be  programmed.  Furthermore,  individual  P^  values  may 
be  programmed  by  the  user  for  a  weapon  against  several  types  of  targets  [Ref.  13:p.  4-4]. 
For  example,  the  user  might  give  P^  of  0.85  against  a  MiG-27,  but  the  same  missile  may  be 
given  a  Pr  of  only  0.70  against  a  MiG-29  in  the  same  scenario. 

3.  Anti-Weapons 

The  Pj.  of  a  weapon  may  be  affected  within  a  simulation  by  the  employment  of  chaff 
or  decoys.  Such  deceptive  countermeasures  are  modeled  in  EADSIM  as  "anti- weapons".  The 
presence  of  an  anti-weapon  will  reduce  the  of  the  weapon  for  that  engagement.  This  is 
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accomplished  by  the  anti-weapon  having  a  value  of  its  own.  For  example,  an  anti-weapon 
with  a  value  of  0.5  will  reduce  the  of  a  weapon  by  50%. 

4.  Kill  or  Survive 

With  the  exception  of  damage  to  an  airbase,  engagements  in  EADSIM  are  ail-or- 
nothing  events.  Therefore,  the  engagement  outcomes  are  modeled  as  "kill"  or  "no-kill" 
events.  A  kill  or  no-kill  outcome  is  determined  by  a  random  number  draw  against  the  of 
a  weapon.  If  the  P^  is  greater  than  the  random  number  draw,  then  the  engagement  is  a  kill 
[Ref.  13:p.  4-31].  The  coding  of  a  random  number  generator  in  C  is  discussed  in  Chapter  V. 
The  comparison  of  P^  versus  the  random  number  (r)  can  be  written  in  one  line  of  C. 
if  (Pk>r)  kill=l; 

The  above  statement  assumes  that  "kill=r'  in  the  program  is  a  successful  engagement. 

B.  WEAPONS  CREATED  FOR  THIS  STUDY 

To  conduct  this  lethality  study,  a  series  of  baseline  weapons  was  created  by  the  author. 
These  "generic"  missiles  have  been  generated  entirely  within  EADSIM  using  hypothetical 
parameters.  This  is  to  avoid  any  direct  correlation  with  real  world  systems  and  to  avoid  all 
possible  classification  restrictions.  The  generic  missiles  do,  however,  correlate  with  the 
missions  of  many  missile  systems  used  in  the  fleet  today.  To  test  these  weapons,  a  scenario 
was  generated  with  one  missile  ship  and  one  imarmed  aircraft  to  act  as  a  target  drone.  The 
ship  was  also  equipped  with  only  one  missile  for  each  run  to  avoid  automatic  re-engagement 
if  the  target  was  not  killed.  For  experimental  consistency,  the  drone  flew  a  level  flight  path 
toward  the  ship.  Altitude  of  the  drone  was  increased  for  the  longer  range  missiles  so  that  it 
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would  stay  above  the  ship's  radar  horizon.  No  jamming  or  countermeasures  were  present,  as 
they  would  effect  sensor  and  weapon  performance. 

1.  Point  Defense  SAM 

The  point  defense  SAM  in  this  study  simulates  a  typical  close-in  missile  system  that 
may  be  found  on  any  warship,  small  combatant,  or  auxiliary  ship.  It  has  a  range  of  five 
kilometers,  or  approximately  three  nautical  miles.  A  point  defense  missile  is  used  as  a  last 
ditch  defense  against  an  attack.  Point  defense  systems  are  considered  to  be  effective  only  in 
defense  of  the  ship  on  which  it  is  installed. 

2.  Short  Range  SAM 

The  short  range  SAM  of  this  study  simulates  a  typical  missile  system  that  may  be 
found  on  a  typical  destroyer,  frigate,  or  large  auxiliary  ship.  It  has  a  range  of  1 S  kilometers, 
or  approximately  eight  nautical  miles.  A  short  range  missile  system  offers  increased  range 
over  point  defense  systems  and  has  a  limited  capability  against  crossing  targets.  Therefore, 
a  ship  equipped  with  a  short  range  missile  'an  perform  escort  duties  if  stationed  close  to  the 
unit  it  is  assigned  to  defend. 

3.  Medium  Range  SAM 

The  medium  range  SAM  of  this  study  simulates  a  typical  missile  system  that  may  be 
found  on  an  older  guided  missile  ship  and  has  a  range  of  50  kilometers,  or  approximately  27 
nautical  miles.  A  medium  range  missile  system  provides  improved  defense  over  the  short 
range  system.  It  can  engage  crossing  targets  at  a  greater  range  and  escort  positioning  is  not 
as  critical. 
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4.  Long  Range  SAM 

The  long  range  SAM  of  this  study  simulates  a  modem  area  defense  missile  that  may 
be  found  on  a  guided  missile  cruiser  or  large  guided  missile  destroyer.  It  has  a  range  of  100 
kilometers,  or  approximately  S5  nautical  miles.  A  ship  equipped  with  an  area  defense  missile 
system  need  not  be  stationed  close  to  the  unit(s)  it  is  assigned  to  defend.  A  long  range 
missile  provides  an  air  defense  umbrella  for  die  ship  and  other  units  operating  with  it. 

5.  Extended  range  SAM 

The  extended  range  SAM  of  this  study  simulates  a  new  generation  of  area  defense 
missiles.  It  has  a  range  of  200  kilometers,  or  ^proximately  110  nautical  miles.  The 
extended  range  of  the  missile  allows  a  surface  ship  to  participate  in  the  outer  air  battle.  It 
also  enables  surface  ships  to  engage  bombers  with  long  range  ASCM's  beyond  their  normal 
weapon  release  range. 

C.  RESULTS  DUE  TO  MODIFICATION  OF  PROBABILITY  OF  KILL 

The  we^ons  modeled  for  this  study  were  given  different  probabilities  of  kill  against  the 
same  target.  Each  weapon  was  given  values  of  0.50,  0.65,  and  0.80  for  each  set  of 
scenario  runs.  The  five  missiles  were  then  individually  employed  against  the  target  aircraft 
at  the  three  values  of  P^.  A  total  of  fifteen  sets  of  scenario  runs  were  conducted  in  this 
study,  with  ten  runs  being  conducted  for  each  set. 

1.  Monte  Carlo  Runs 

The  Monte  Carlo  options  were  set  for  ten  runs  of  each  missile,  at  each  value  of  P^, 
to  be  conducted  consecutively.  This  feature  also  allows  a  different  random  number  seed  to 
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be  selected  for  each  run.  Varying  random  number  seed  is  critical  in  such  a  controlled 
scenario.  Otherwise,  the  same  results  will  occur  for  each  scenario  run. 

2.  Results 

Table  U  contains  the  results  of  the  multiple  scenario  runs  for  each  missile  at  each 
P^.  A  direct  correlation  between  the  probability  of  kill  and  the  number  of  targets  killed  was 
observed  in  this  study.  For  the  different  missiles,  range  did  not  have  an  effect  on  the 
simulation  results  as  expected.  EADSIM  will  fire  a  weapon  when  the  target  enters  the 
weapon's  lethal  range. 

TABLE  n  -  RESULTS  OF  PROBABILITY  OF  KILL  STUDY 

Number  of  kills  in  10  attempts 


Point 

Short 

Medium 

Long 

Extended 

Pk  Value 

Defense 

Range 

Range 

Range 

Range 

SAM 

SAM 

SAM 

SAM 

SAM 

Pk  =  0.50 

4 

3 

5 

5 

6 

Pk  =  0.65 

8 

5 

6 

5 

6 

Pk  =  0.80 

7 

8 

9 

9 

9 
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D.  MISSILE  LETHALITY  ENVELOPES 
1.  Real  World  Envelopes 

Real  world  missile  systems  have  lethality  envelopes  based  upon  the  missile's  They 
are  generally  based  upon  a  P^ss  value  of  0.5,  but  lethality  envelopes  for  any  Pjjss  can  be 
developed.  These  envelopes  enclose  a  volume  based  upon  the  range,  azimuth,  and  altitude 
of  a  target  and  can  be  given  as  missile  launch  or  intercept  lethality  envelopes.  Figure  1 
depicts  a  typical  missile  lethality  envelope  based  on  intercept.  [Ref  2] 


Figure  2  -  Typical  Missile  Lethality  Envelope 


2.  Modificafions  to  P,;  Within  EADSIM 


Because  the  missile  firing  doctrine  in  EADSIM  has  the  system  to  make  the  earliest 


possible  intercept,  the  creation  of  envelopes  using  EADSIM  data  would  not  be  realistic. 
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These  envelopes  would  be  shaped  such  that  the  majority  of  the  engagements  would  be 
conducted  at  the  outer  edges  of  the  missile’s  lethal  range.  Figure  2  depicts  what  an  EADSIM 
missile  lethality  envelope  may  look  like  with  engagements  made  at  maximum  range 


Figure  2  -  EADSIM  Missile  Lethality  Envelope 
a.  I»kRo>I-0*T 

Probability  of  kill  roll-off  parameters  may  be  programmed  by  the  user  in  an 
attempt  to  model  an  engagement  envelope.  The  envelope  begins  with  a  user  specified  and 
remains  constant  out  to  the  "Begin  Roll-OfT  percentage  of  the  lethal  range  against  the  target. 
The  Pk  then  rolls  off  linearly  from  the  user  specified  P^  at  the  selected  Begin  Roll-Off  range 
to  the  "End  Roll-Off  range.  End  Roll-Off  range  is  also  a  percentage  of  the  weapon's  lethal 
range.  Probability  of  kill  roll-off  is  only  modeled  for  the  SAM  systems.  [Ref  14]  Figure  3 
depicts  what  an  EADSIM  missile  lethality  envelope  would  look  like  with  the  roll-off  feature 
enabled. 
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Figure  3  -  Missile  Lethality  Envelope 
With  Pk  Roll-Off  Enabled 

The  author's  experience  with  roll-off  within  the  program  indicates  that  this  feature  does 
not  work  properly.  Tests  similar  to  the  original  P^  study  were  conducted  with  the  roll-off 
feature  enabled,  but  did  not  indicate  appreciably  different  results, 
b.  Pk  Tables 

Probability  of  kill  tables  could  be  created  to  model  lethality  envelopes.  The  tables 
could  be  a  matrix  of  P^'s  based  upon  the  target’s  range  and  altitude.  Factors  such  as  target 
velocity  and  target  crossing  angle  could  be  modeled  in  the  same  manner.  User  selectable 
parameters  would  be  a  useful  option,  such  as  user  determined  Pjc’s  against  different  aircraft 
types.  The  next  release  of  the  EADSIM  software,  discussed  in  the  coming  chapter,  will 
include  P^  tables.  Figure  4  depicts  a  real  world  missile  lethality  envelope  for  a  medium  or 
long  range  missile  that  can  be  modeled  using  P^  tables. 


Default 
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VII.  FUTURE  DEVELOPMENT 


A.  FUTURE  GROWTH  OF  EADSIM 
1.  EADSIM  Version  3.00 

The  Extended  Air  Defense  Simulation  has  evolved  into  a  major  program  since  its 
initial  inception.  Future  growth  of  the  program  will  continue  as  long  as  EADSIM  remains 
an  effective  air  defense  model  and  further  upgrades  are  made  to  meet  the  needs  of  users. 
The  next  generation  of  EADSIM  software  is  Version  3.00  (V3.00),  scheduled  for  release 
in  late  June  1993.  It  will  incorporate  many  of  the  changes  requested  by  EADSIM  users 
and  will  offer  some  enhanced  modeling  features.  Some  of  the  features  involved  will 
allow  smoother  model  operation,  while  others  will  improve  the  fidelity  of  a  simulation. 
Many  of  the  enhancements  being  incorporated  into  the  new  baseline  (V3.00)  software 
were  presented  at  the  last  EADSIM  User's  Group  Meeting  [Ref.  15].  Nearly  100 
EADSIM  users  were  in  attendance.  A  listing  of  all  organizations  currently  registered  as 
EADSIM  users  is  contained  in  Appendix  F. 
a.  Major  Enhancements 

Among  the  most  important  new  features  with  respect  to  this  project,  is  the 
addition  of  tables.  This  will  allow  a  more  realistic  outcome  of  an  engagement.  The 
tables  will  be  represented  by  a  multidimensional  array  of  probabilities.  Each  will 
represent  the  Pj.  for  a  parti''ular  engagement  type  (e.g.,  air-to-air,  surface-to-air,  etc.)  based 
upon  a  variety  of  dynamic  factors.  The  parameters  include  range,  altitude,  velocity. 
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azimuth  and  elevation.  User  selectable  combinations  of  parameters  can  be  entered  prior 
to  a  scenario  run.  By  modeling  the  terminal  engagement  in  this  manner,  crossing  angle 
limitations,  aspect  angle,  and  other  geometric  considerations  can  be  represented  in  a 
simulation.  The  tables  will  improve  the  fidelity  of  engagements  because  all 
engagements  are  different  and  not  merely  a  result  of  a  random  number  draw  as  currently 
modeled. 

fCill  assessment  has  also  been  considered  a  weakness  in  the  modeling  process. 
In  its  current  form,  kill  assessment  is  based  upon  truth  data.  Therefore,  if  a  target  is 
killed,  it  is  removed  from  the  scenario.  Targets  remaining  alive  are  automatically 
assessed  as  being  alive  and  can  be  re-engaged.  The  new  kill  assessment  routine  includes 
error  modeling.  This  enables  "dead"  targets  to  be  assessed  as  "alive,"  resulting  in  false 
alarms.  Conversely,  "alive"  targets  assessed  as  "dead"  will  appear  as  leakers,  or  missed 
targets.  The  error  modeling  is  based  upon  preprogrammed  false  alarm  rates  and  leaker 
rates  as  selected  by  the  user.  [Ref  16] 

The  Aircraft  Flight  Model  within  EADSIM  has  been  a  simplistic  three  degree 
of  freedom  representation.  Currently,  EADSIM  models  only  forces  that  impact  on  aircraft 
acceleration,  which  is  not  a  true  force  model  [Ref.  12].  Near  term  enhancemc'nts  will 
include  a  constant  altitude  flight  path,  replacing  the  current  straight  line  flight  path  which 
does  not  accoimt  for  curvature  of  the  earth.  Other  improvements  will  allow  radius  of  turn 
and  turn  rates  for  specific  aircraft  types,  user  specified  formations,  F-pole  maneuvers,  and 
drag  maneuvers  [Ref  16].  Another  possibility  for  future  inclusion  is  a  five  degree  of 
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freedom  energy  model  that  analytically  represents  the  dependency  of  available  thrust  on 
mach  and  altitude. 

Infra-red  sensor  modeling  will  be  incorporated  into  EADSIM  V3.00.  Areas 
to  be  represented  are  target  signature,  clutter,  and  path  loss.  An  atmospheric  model, 
LOWTRAN,  is  used  to  generate  clutter  and  path  loss.  Adding  an  infra-red  c^ability  to 
EADSIM  allows  the  representation  of  IR  sensors  and  IR  missile  seekers  within  the  model. 
[Ref.  16] 

The  enhanced  radar  model  of  V3.00  will  account  for  radar  propagation  effects 
in  the  atmosphere  [Ref  15],  Clutter  and  noise  will  reduce  radar  performance  within  the 
model  in  a  manner  emulating  real  world  losses.  Expanded  antenna  modeling  will  allow 

r~" 

th^^odeling  of  nulls  and  lobes  in  a  radar  antenna  pattern.  Currently,  only  the  main  beam 
of  a  radar  is  modeled.  The  enhanced  radar  model  greatly  improves  upon  the  current 
modeling  of  the  free  space  radar  range  equation  as  discussed  in  Chapter  III  of  thi'-  ^hesis. 
Again,  higher  fidelity  is  achieved  in  another  important  aspect  of  AAW  simulation. 

Other  improvements  being  made  to  V3.00  include  a  non-graphical  post 
processor,  improved  Monte  Carlo  execution,  and  a  new  ballistic  missile  model.  All  of 
these  improvements  are  designed  to  add  to  the  usefulness  of  the  model  and  to  make  the 
model  more  user  friendly.  [Ref  16] 
b.  Sun  System  Compatible 

Version  3.00  of  the  EADSIM  software  offers  new  potentials  concerning  its  use. 
This  new  version  is  compatible  with  the  Sun  Computer  Systems'  SPARCStation  2  series 
workstations,  as  well  as  the  SGI  workstations  in  which  EADSIM  currently  runs.  Previous 
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releases  could  only  run  on  Silicon  Graphics  workstations.  A  reduced  icon  set  is  used  for 
the  Sun  to  speed  model  operation.  Graphics  accelerator  boards  may  also  be  installed  into 
a  Sun  workstation  to  improve  system  performance.  The  numerical  results  when  run  on 
a  Sun,  however,  are  nearly  identical  to  SGI  results.  Test  have  shown  a  variance  of  less 
than  one  per  cent  in  simulation  results  [Ref.  16],  The  software  installation  is  the  same 
for  both  types  of  computer  systems.  The  differences  in  the  load  subroutines  are 
transparent  to  the  operator.  While  the  software  is  being  loaded,  it  recognizes  the 
operating  system  of  the  host  computer  workstation  in  which  it  is  being  installed, 
c.  Integration  of  Site  Modifications 

Much  of  the  work  involved  with  the  previous  improvements  has  been  done  at 
sites  other  than  Teledyne  Brown  Engineering.  Other  organizations  have  conducted  source 
code  modifications  to  EADSIM  and  hav"'  requested  that  their  modifications  become  part 
of  the  EADSIM  baseline.  The  procedure  for  submitting  the  Software  Change  Requests 
is  discussed  in  Chapter  II  of  this  thesis  Once  approved,  the  software  improvements  are 
scheduled  for  integration  into  a  subsequent  release  of  an  EADSIM  baseline. 

Some  of  the  major  contributions  to  EADSIM  V3.00  by  other  organizations  are 
given  below.  They  are  being  integrated  into  the  baseline  by  TBE.  Lockheed  is 
responsible  for  the  infra-red  sensor  capability  ir^'orporated  into  V3.00  [Ref.  16]. 
Lockheed  has  also  written  new  procedures  for  aircraft  reaction  to  a  SAM  threat  [Ref  17]. 
Raytheon  has  assisted  wi+h  the  development  of  the  tables  [Ref  16].  CAS  Incorporated 
and  the  SHAPE  Technical  Center  are  responsible  for  display  improvements  and  improved 
methods  in  which  to  edit  a  platform  [Ref  18].  JADO/JEZ  has  done  work  in  numerous 
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areas  including  improved  fighter  tactics  and  multiple  simultaneous  aircraft  engagements 
[Ref.  19],  The  Center  for  Naval  Analysis  has  introduced  new  fighter  vectoring 
procedures  for  EADSIM  [Ref  20], 

2.  EADSIM  Version  4.00 

Because  EADSIM  is  continually  receiving  improvements,  new  releases  of  the 
software  come  out  several  times  each  year.  The  next  major  release  of  EADSIM  following 
V3.00  will  be  Version  4.00,  which  is  already  under  development.  The  proposed  release 
date  for  V4.00  is  scheduled  for  December  1993.  This  new  release  will  include  some 
improvements  that  were  originally  slated  for  V3.00,  but  could  not  be  included  because  of 
time  constraints.  Other  enhancements  will  be  entirely  new  features.  As  with  the  V3.00 
upgrade,  organizations  other  than  TBE  are  responsible  for  some  of  the  software 
improvements. 

Major  enhancements  of  EADSIM  V4.00  will  include  improvements  in  Electronic 
Warfare.  Currently,  electronic  warfare  is  limited  to  the  jamming  of  communications 
systems  and  radar  sensors.  EADSIM  V4.00  will  model  counterforce,  which  involves  a 
strike  against  other  surface-to-surface  missile  sites.  This  will  allow  automatic  targeting, 
scheduling,  and  launch  of  surface-to-surface  missile  engagements  within  the  simulation. 
As  the  model  currently  exists,  all  surface-to-surface  engagements  are  pre-scripted.  Air 
defense  artillery  (ADA),  also  known  as  anti-air  artillery  (AAA),  is  another  new  feature 
of  the  V4.00  model.  The  air  defense  artillery  model  will  allow  the  user  to  employ  such 
assets  in  a  scenario.  Future  improvements  in  this  area  may  include  the  modeling  of 
directed  energy  weapons.  Such  systems  have  been  sucessfully  modeled  using  a  gun  with 
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a  very  high  muzzle  velocity  and  a  high  probability  of  kill.  The  actual  simulation  of  an 
energy  weapon  beam  has  yet  to  be  accomplished  within  EADSIM. 

Other  new  features  of  V4.00  will  include  modeling  of  track  management, 
incorporation  of  an  air  tasking  planner,  and  the  addition  of  a  database  management 
system.  The  commercially  available  Oracle  database  manager  has  received  much 
attention  because  the  software  for  the  Extended  Air  Defense  Test  Bed  (EADTB)  is  being 
developed  to  be  compatible  with  Oracle.  In  order  to  achieve  commonality,  it  would  be 
logical  for  EADSIM  to  use  the  same  database  management  system.  [Ref  21] 

3.  The  Extended  Air  Defense  Test  Bed 

The  purpose  of  the  Extended  Air  Defense  Test  Bed  (EADTB)  is  to  provide  a 
simulation  and  analysis  capability  far  beyond  that  of  EADSIM.  As  a  follow  on  to 
EADSIM,  which  is  considered  to  be  its  prototype,  EADTB  will  also  be  a  many  on  many, 
two  sided,  fully  interactive  theater  level  simulation.  EADTB  is  several  orders  of 
magnitude  more  powerful  than  EADSIM,  but  is  not  intended  to  replace  it.  It  is  planned 
for  one  system  to  complement  the  other  and  that  EADSIM  users  provide  data  for  the 
EADTB  program  as  it  evolves.  Besides  studying  present  air  defenses,  EADTB  will  be 
able  to  analyze  future  defenses,  evolving  air  threats,  and  technology  applications. 
EAD13  will  be  used  by  material  developers,  combat  developers,  and  operational 
commanders.  It  will  provide  decision  makers  with  a  basis  for  optimizing,  prioritizing,  and 
maximizing  scarce  research  and  development  resources.  [Ref.  22] 

An  EADTB  node  is  a  complete  hardware  and  software  system.  Each  node  will 
have  its  own  Convex  38‘40  mainframe  computer.  This  system  has  similar  processing 
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capabilities  to  that  of  the  Cray  Y-MP  EL  mainframe  of  the  NPS  Visualization  Lab.  The 
software  used  by  EADTB  is  written  in  Ada,  C,  and  Fortran-77.  A  node  can  be  run  stand 
alone,  or  can  be  networked  with  other  EADTB  nodes.  The  first  node  is  scheduled  to 
receive  an  initial  operational  capability  (IOC)  in  October  1993  at  the  Advanced  Research 
Center  in  Huntsville,  Alabama.  The  second  node  will  go  to  the  Army  Air  Defense 
Artillery  School  at  Ft.  Bliss,  Texas.  The  third  node  is  slated  for  use  at  the  SHAPE 
Technical  Center  in  The  Hague,  Netherlands.  An  additional,  fourth  site  may  by  be 
installed  at  Kirkland  AFB,  New  Mexico.  Potential  user  sites  and  network  coimections 
include  the  Naval  Surface  Weapons  Center  (NSWC),  the  Naval  Air  Warfare  Center 
(NAWC),  the  Air  Force  Studies  and  Analysis  Agency  (AFSAA),  and  the  Army  Concepts 
and  Analysis  Agency  (CAA).  [Ref  22] 

The  EADTB  program  is  a  joint  project  and  has  received  active  Air  Force 
participation  from  program  inception.  Because  air  defense  is  a  joint  mission,  plans 
include  the  modeling  of  all  air  defense  issues,  including  Naval  anti-air  warfare.  In  this 
light,  it  is  expected  that  EADTB  will  receive  increased  Navy  participation.  All  naval 
AAW  systems  should  be  modeled  in  EADTB,  especially  Aegis. 

4.  EADSIM  Unclassified  Database 

The  Space  and  Strategic  Defense  Command  has  sponsored  CAS  Incorporated  to 
develop  a  standard  unclassified  database  for  EADSIM.  The  values  within  the  database 
will  more  closely  represent  real  world  specifications.  The  standardized  database  will  have 
documented  references.  Previously,  many  EADSIM  users  were  reluctant  to  use  the 
existing  values  within  the  EADSIM  library  because  of  their  questionable  validity.  As  a 
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result,  the  users  were  spending  time  developing  their  own  research  data  for  EADSIM  use. 
The  new  database  will  also  include  on-line  assistance  for  deploying  platforms  and 
systems  during  Scenario  Generation.  The  first  segment  of  the  database  will  be  available 
at  31  July  1993,  it  will  include  aircraft  parameters  The  second  segment,  available  31 
October  1993,  will  cover  weapons  and  communications  devices.  The  third  segment, 
available  30  November  1993,  will  cover  protocols.  The  fourth,  available  15  February 
1994,  will  cover  sensors.  The  fifth,  available  15  March  1994,  will  cover  RCS  and 
Jammers.  The  sixth,  available  15  April  1994,  will  cover  rule  sets.  [Ref  23] 

B.  OTHER  CONCEPTS  TO  INCORPORATE  INTO  EADSIM 

The  author  has  noted  other  faults  within  EADSIM  and  has  made  the  following 
suggestions.  Some  of  these  suggestions  are  aimed  at  fixing  major  shortcomings  of  the 
model,  while  others  are  intended  to  add  a  higher  level  of  fidelity. 

1.  Missile  Fly-out 

The  author  is  not  the  only  user  who  feels  that  the  greatest  flaw  in  EADSIM  as  a 
learning  tool  is  a  lack  of  missile  fly-out.  This  fact  has  been  mentioned  several  times 
throughout  this  thesis  and  was  the  subject  of  discussion  at  the  last  User's  Group 
conference.  To  conduct  an  explicit  missile  fly-out,  an  existing  missile  model  must  be 
integrated  into  EADSIM,  or  a  new  module  must  be  created. 

2.  Improve  Fidelity  of  Naval  Assets 

Currently  EADSIM  models  naval  assets  in  the  same  manner  as  it  does  ground 
assets.  To  improve  fidelity  of  naval  AAW,  specific  rule  sets  should  be  developed  for 
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ships.  An  aircraft  carrier,  for  example,  acts  as  a  floating  air  base  within  EADSIM.  What 
is  not  modeled  are  all  the  capabilities  and  the  self  defense  we£^)ons  of  a  carrier.  To 
resolve  this  dilemma,  an  Aircraft  Carrier  rule  set  should  be  created.  Guided  missile  ships 
also  suffer  from  the  same  lack  of  fidelity.  The  Aegis  cruiser  used  in  the  scenarios 
developed  for  NFS,  was  modeled  using  modifications  of  the  Patriot  missile  and  radar 
systems.  Because  of  their  superior  sensor,  weapon  control,  and  missile  launch 
capabilities,  there  should  be  a  special  rule  set  for  Aegis  ships.  Modeling  of  other  ships, 
such  as  frigates  and  New  Threat  Upgrade  (NTU)  cruisers  is  also  difficult  to  accomplish. 
The  EADSIM  library  needs  to  incorporate  common  naval  search  radars  such  as  the  SPS- 
48E  and  the  SPS-49,  and  missile  fire  control  systems  such  as  the  Mk  76  and  Mk  92.  In 
addition,  EADSIM  needs  to  include  varients  of  the  AN/SLQ-32  ESM/ECM  suite,  which 
is  installed  in  virtually  every  surface  combatant  in  the  U.S.  fleet. 

3.  Weapon  Modification 

An  improved  selection  of  weapons,  especially  air-to-air  and  surface-to-air  missiles, 
would  enable  the  user  to  "mix"  the  weapons  load  of  a  unit  being  modeled.  Naval  SAM's 
are  particularly  lacking  in  the  current  EADSIM  library,  where  only  one  type  of  the 
Standard  Missile  family  can  be  found.  Other  weapons,  such  as  NATO  SeaSparrow  and 
the  Rotating  Airframe  Missile  (RAM)  are  not  included  in  the  library.  The  Navy's  premier 
AAM,  Phoenix,  is  also  not  modeled.  To  be  able  to  more  accurately  model  naval  AAW, 
these  weapons  must  be  included  in  the  EADSIM  library. 

Another  desired  feature  would  be  the  capability  to  model  warhead  effects. 
Currently,  weapons  can  either  miss  or  kill  a  target.  The  only  method  to  change  the 
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lethality  of  a  weapon  is  to  vary  the  default  P^.  Other  AAW  models  have  incorporated 
end  game  effects.  This  would  add  a  tremendous  amount  of  fidelity  to  the  engagement 
aspect  of  a  simulation. 

C.  EADSBVf  INTERFACE  WITH  OTHER  MODELS 

1.  Patriot  Tactical  Operations  Simulator 

The  Patriot  Tactical  Operations  Simulator,  PTOS,  is  the  Army's  main  training 
device  for  the  Patriot  missile  system.  By  interfacing  PTOS  with  EADSIM,  the  individual 
strengths  of  the  two  models  can  complement  one  another.  This  interface  allows  PTOS 
to  act  as  Patriot  battery  within  an  EADSIM  scenario.  The  use  of  mixed  fidelity  models 
allows,  in  this  case,  allows  man-in-the  loop  operations  within  EADSIM.  As  such, 
EADSIM  becomes  a  training  tool  and  an  analysis  tool.  [Ref  24] 

2.  TAC  Brawler 

The  motivation  behind  the  integration  of  EADSIM  and  TAC  Brawler  was  that  no 
simulation  does  everything.  Analysts  must  frequently  use  several  models,  each  of  which 
handles  only  a  part  of  the  overall  picture.  They  then  have  to  try  to  combine  the  results 
from  different  studies  to  produce  a  sensible  final  answer.  One  solution  is  to  combine 
several  models  in  such  a  way  that  each  handles  the  parts  of  the  scenario  that  it  does  best. 
By  combining  EADSIM  with  TAC  Brawler,  higher  fidelity  air-to-air  engagements  are 
possible.  TAC  Brawler  provides  aircraft  aerodynamics,  air-to-air  missiles,  air  intercept 
radar,  other  avionics,  and  a  pilot  model.  It  also  provides  for  improved  SAM  modeling 
with  a  reactive  air  target,  but  is  not  a  substitute  for  a  true  SAM  model.  [Ref  25] 


63 


3.  Ground  Attack  Fighter  Bomber  Model  Software 

The  Ground  Attack  Fighter  Bomber  Model  Software,  GAFMS  O,  is  another 
integration  of  existing  models.  In  this  case,  GAFMS  acts  as  a  cradle  for  EADSIM, 
FLAPS  (Force  Level  Automated  Planning  System),  and  RAIDES  (Rapid  Air  Defense 
Evaluation  System).  FLAPS  is  a  model  used  to  plan  air  attacks.  It  allocates  air  assets, 
plans  routes,  and  assigns  targets.  RAIDES  is  a  model  used  for  air  defense  planning.  It 
chooses  air  defense  sites  and  orients  air  defense  sensors.  GAFMS  provides  a  common 
database  that  allows  the  different  models  to  inter-operate.  By  providing  the  interface. 
GAFMS  allows  easy  integration  of  other  models.  A  problem  with  such  an  integration  is 
the  ammount  of  computer  code  needed  to  accomplish  the  task.  GAFMS  requires  moie 
coding  than  any  of  the  models  that  it  integrates  (320,000  +  lines  of  code  for  GAFMS, 
vs.  300,000  lines  of  code  for  EADSIM,  100,000  lines  fo  code  for  RAIDES,  and  94,500 
lines  of  code  for  FLAPS).  [Ref  26] 

D.  A  COMPARISON  WITH  ACES/PHOENIX 
1.  Brief  Description  of  ACES/Phoenix 

ACES/Phoenix  is  another  air  defense  model  that  is  being  studied  in  a  thesis  project 
parallel  to  this  thesis.  Lieutenant  John  Armantrout  is  using  the  ACES/Phoenix  model  in 
his  thesis  Adaptation  of  ACES/Phoenix  for  Survivability  and  Lethality  Assessment  at  the 
Naval  Postgraduate  School. 
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ACES/Phoenix  is  a  software  tool  that  enables  an  analyst  to  perform  efficient  modeling 
and  simulation  of  aircraft  survivability  and  air  defense  lethality  in  a  user-friendly  computer 
environment.  ACES/Phoenix  uses  community  accepted  models  for  simulating  surface-to- 
air  missile  engagements,  radar  directed  gun  engagements,  and  air-to-air  missile 
engagements  against  a  single  aircraft.  [Ref  27] 

ACES/Phoenix  is  a  software  package  that  allows  simultaneous  operation  of  a  variety  of  high 
fidelity  models.  The  Adaptive  Combat  Environment  System,  ACES,  provides  the  cradle  for  the 
different  models  to  interface  with.  Phoenix  provides  a  common  graphical  user  interface  for  the 
software  package. 

2.  Similarities  Between  the  Models 

Although  the  two  models  are  designed  to  simulate  different  aspects  of  the  air  defense 
spectrum,  they  have  some  similarities.  The  main  similarity  is  that  they  both  operate  under  UNIX 
in  a  graphical  user  interface.  Both  models  have  their  own  windowing  system  and  are  capable 
of  modeling  an  entire  integrated  air  defense  at  any  location  on  the  Earth.  EADSIM  and 
ACES/Phoenix  allow  modification  of  the  systems  being  modeled,  can  be  run  Monte  Carlo 
perform  terrain  modeling  (using  DMA  data),  and  have  a  radar  clutter  map  (EADSIM  V3.00). 
In  addition,  both  models  are  certified  to  run  at  a  Secret  level  of  classification. 

3.  Differences  Between  the  Models 
a.  Advantages  of  EADSIM 

The  primary  advantage  of  EADSIM  is  that  it  can  model  a  two  sided,  many-on-many 
scenario.  ACES/Phoenix  is  limited  to  a  single  sided,  one-on-many  (Blue  aircraft  against  Red  air 
defense)  scenario.  EADSIM  can  model  naval  warships,  ACES/Phoenix  can  not.  EADSIM  has 
superior  C^I  modeling  and  provides  for  modeling  of  multiple  tiers  of  C^I  networks 
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ACES/Phoenix  can  only  model  one  tier  of  of  a  command  and  control  network.  Another 
advantage  of  EADSIM  is  its  graphical  capabilities  with  scenario  playback.  A  benefit  that 
EADSIM  also  enjoys  is  its  widely  accepted  use  (over  one  hundred  registered  user  sites)  and  the 
support  of  SSDC.  ACES/Phoenix,  although  it  is  a  SURVIAC  (Survivability /Vulnerability 
Information  Analysis  Center)  supported  model,  does  not  have  such  a  large  user  base, 
b.  Advantages  of  ACES/Phoenix 

The  major  advantage  of  ACES/Phoenix  is  that  it  is  an  engineering  level  model.  As 
such,  it  has  much  higher  fidelity  in  many  areas  of  air  defense  modeling.  These  include  missile 
fly-out,  aspect  dependent  radar  cross  section,  specific  IR  signatures  for  aircraft,  and  modeling  of 
explicit  kill  and  endgame  effects.  None  of  these  features  are  available  within  EADSIM.  Another 
major  advantage  of  ACES/Phoenix  is  that  it  may  run  on  any:  UNIX  based  computer  workstation. 
ACES/Phoenix  has  an  integrated  cradle  of  community  accepted  models  that  also  allows  for  easy 
integration  of  other  models.  Integration  of  other  models  with  EADSIM  requires  a  great  deal  of 
coding  and  has  not  been  attempted  with  many  models.  Another  clear  advantage  of 
ACES/Phoenix  is  that  it  is  relatively  easy  to  use.  EADSIM  is  difficult  to  learn  and  even  more 
difficult  to  use. 

4.  Computer  Models  as  Tools 

In  either  case,  EADSIM  and  ACES/Phoenix  are  designed  as  educational  and  training  tools. 
They  both  serve  a  purpose  in  analysis  of  different  aspects  of  air  defense.  With  a  shrinking 
defense  budget,  researchers  will  have  to  turn  to  computer  modeling  and  simulation  to  determine 
the  feasibility  of  future  aircraft  and  weapon  system  designs. 
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Xlll.  SUMMARY,  CONCLUSIONS,  AND  RECOMMENDATIONS 

A.  SUMMARY 

L  Model  Selection,  Installation,  and  Operation 

The  primary  goal  of  this  thesis  was  to  develop  a  capability  to  model  naval  AAW 
systems  at  NFS.  Before  the  actual  model  selection,  a  variety  of  air  defense  models  were 
investigated.  Most  of  the  potential  choices  were  from  the  Catalog  of  Wargaming  and 
Military  Simulation  Models.  The  catalog  lists  the  capabilities  of  the  models  as  well  as 
the  hardware  requirements.  To  make  a  selection,  the  model  had  to  meet  the  prerequisites 
of  this  project  and  the  equipment  in  which  to  install  the  model  had  to  be  available  or 
attainable.  The  outcome  of  this  selection  process  was  the  choice  of  the  Extended  Air 
Defense  Simulation  (EADSIM). 

EADSIM  is  a  sophisticated  and  powerful  model  that  can  simulate  many  aspects 
of  air  warfare.  It  requires  a  Silicon  Graphics  computer  workstation  with  a  24-bit  graphics 
plane.  Other  recommended  system  capabilities  are  a  minimum  of  64  Megabytes  of  RAM 
and  1.2  Gigabytes  of  hard  disk  storage  space.  The  Computer  Center  Visualization  Lab 
has  a  network  of  SGI  workstations,  one  of  which  is  a  Power  Series  380/VGX.  This 
computer  has  eight  parallel  processors  and  128  Megabytes  of  RAM.  In  other  words,  it 
more  than  met  the  system  requirements  of  EADSIM.  There  was,  however,  a  lack  of 
available  hard  disk  storage  space  in  the  Visualization  Lab.  Therefore,  a  new  2.1  Gigabyte 


fast  SCSI"  hard  disk  was  acquired. 


Once  EADSIM  was  selected,  a  copy  of  the  software  had  to  be  acquired  and 
installed.  Representatives  from  Teledyne  Brown  Engineering  and  the  Space  and  Strategic 
Defense  Command  brought  a  copy  of  the  EADSIM  software  to  NFS  for  installation, 
demonstration,  and  instruction.  The  installation  process  was  difficult.  The  open 
purchased  hard  disk  had  not  yet  arrived  and  another  storage  site  for  EADSIM  had  to  be 
found.  The  Physics  Simulation  Lab  has  a  Sun  Systems  {SPARCServer)  file  server  that 
had  more  than  adequate  storage  space  available.  Loading  and  operating  the  EADSIM 
software  over  the  ethemet  network  proved  to  be  a  tedious  process.  This  was  further 
complicated  by  corrupted  software.  The  tape  provided  by  TBE  had  been  previously  run 
on  a  workstation  that  had  a  "Beta"  copy  of  EADSIM  Version  3.00  installed  This 
reformatted  all  the  scenario  information  on  the  Version  2.07  tape  provided.  The  net  result 
was  that  a  working  copy  of  EADSIM  was  not  available  at  NPS  for  another  six  weeks. 
A  new  copy  of  the  V2.07  software  was  obtained  and  installed  directly  onto  the  new  hard 
disk  that  had  also  arrived. 

Operation  of  EADSIM  is  conducted  through  a  graphical  user  interface  (GUI).  The 
GUI  allows  the  user  access  to  the  various  routines  and  on-line  tools  of  EADSIM.  To 
model  the  various  participating  units  of  a  scenario,  a  library  of  platforms  is  available  as 
part  of  the  database.  These  platforms  may  be  modified  by  the  user,  as  well  as  the 
weapons,  sensors,  and  communications  equipment.  Actual  platform  performance  within 
a  scenario  is  governed  by  Rule  Sets.  These  rule  sets  may  be  further  modified  to  meet  the 
needs  of  the  user.  The  selection  of  platforms  and  rule  sets  is  conducted  from  the  Scenario 
Generation  routine  within  EADSIM.  Scenario  Generation  allows  the  initial  laydown  of 
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a  scenario  over  a  graphical  map  file.  Once  the  original  laydown  is  made,  the  scenano  can 
be  saved  to  hard  disk,  edited,  or  run. 

2.  Scenarios 

Two  sets  of  scenarios  were  developed  by  the  author  for  future  use  in  AE3705  "Air 
Defense  Lethality"  and  AE3251  "Aircraft  Combat  Survivability".  The  first  set  of 
scenarios  was  created  for  AE3705.  It  required  the  modeling  of  naval  warships  operating 
in  a  hostile  AAW  environment.  Anti-ship  cruise  missiles  and  attack  aircraft  were  selected 
from  the  EADSIM  library  as  the  adversary.  An  Aegis  cruiser,  a  destroyer,  and  an  aircraft 
carrier  were  selected  as  the  naval  platforms  conducting  the  air  defense.  The  first  scenario 
had  the  cruiser  operating  autonomously  against  the  threat.  The  second  scenario  added  the 
destroyer,  which  was  equipped  with  only  short  range  missiles.  This  scenario  was  run 
twice.  The  first  run  had  the  ships  operating  their  weapon  systems  independently.  The 
second  nm  had  both  ships'  weapon  systems  controlled  by  the  cruiser  over  a  command 
network.  The  third  scenario  added  the  aircraft  carrier.  Because  the  aim  was  to  model 
shipboard  air  defense,  the  carrier’s  air  wing  was  deliberately  omitted.  This  scenario  was 
also  run  twice,  first  with  the  cruiser  exercising  tactical  control  of  the  weapon  systems,  and 
again  with  the  carrier  exercising  tactical  control. 

The  second  set  of  scenarios  was  designed  for  use  in  AE3251.  It  models  a  strike 
by  Navy  aircraft  against  a  defended  airfield.  The  airfield  is  defended  by  a  network  of 
SAM  batteries.  The  first  scenario  has  a  flight  of  F/A-18  Hornets  conducting  a  strike 
against  the  airfield  with  gravity  bombs.  The  second  scenario  gives  stand-off  weapons  to 
the  Hornets  to  minimize  their  exposure  in  the  SAM  envelope.  The  third  scenario  adds 
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anti-radiation  missiles  to  the  strike  package,  along  with  jamming  support  from  an  EA-6B 
ProMler.  The  fourth  scenario  puts  defensive  counter  air  on  CAP  stations  above  the 
airfields.  The  enemy  fighters  are  a  mix  of  MiG-29  Fulcrums  and  F-1  Mirages.  The  fifth 
scenario  provides  escort  fighter  cover  for  the  strike  by  adding  F-14  Tomcats.  The  purpose 
of  this  gradual  escalation  is  to  show  the  cause  and  effect  of  various  offensive  and 
defensive  measures  on  aircraft  survivability. 

3.  Execution 

Scenario  Execution,  another  EADSIM  routine,  allows  the  actual  simulation  of  the 
platforms  involved.  It  is  conducted  by  four  run-time  processes  within  the  program 
These  processes  are  Detection,  C^I,  Propag  ion,  and  Flight  Processing.  Once  a  scenario 
is  run,  the  results  are  sent  to  the  Post  Processor  routine  and  to  the  Scenario  Playback 
routine  Both  routines  offer  the  user  the  opportunity  to  see  the  scenario  results.  The  Post 
Processor  produces  data  files  for  detections,  eng^  ;enients,  and  communications.  These 
files  may  be  turned  into  a  hard  copy  printout  or  downloaded  into  an  off-line  application 
such  as  a  spreadsheet.  The  graphical  Scenario  Playback  provides  perhaps  the  most 
stnking  feature  of  EADSIM.  It  produces  an  animated  playback  of  a  scenario  run  that  is 
viewed  on-line,  directly  on  the  computer  monitor. 

4.  Probability  of  Kill 

A  study  of  the  EADSIM  weapon  performance  model  was  conducted  as  part  of  this 
thesis.  The  default  values  for  the  probability  of  kill  of  individual  ’veapons  were  modified. 
The  results  were  examined  to  determine  the  overall  effect  of  P^  within  a  simulation. 
Generic  models  of  five  types  of  surface-to-air  missiles  were  created.  These  SAM's  were 
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point  defense  (5  km),  short  range  (15  km),  medium  range  (50  km),  long  range  (100  km), 
and  extended  range  (200  km)  missiles  The  study  looked  at  each  weapon  while  was 
altered  for  a  single  engagement.  Multiple  Monte  Carlo  runs  were  then  conducted. 

5,  Future  Growth 

EADSIM  continues  to  evolve  and  meet  the  needs  of  the  user.  The  next  edition 
of  the  software  is  Version  3  00  and  is  scheduled  for  release  in  late  June  1993.  The  V3.00 
release  corrects  some  flaws  that  cunently  exi.sf  in  the  model  and  adds  new  features  to 
increase  its  fidelity.  Among  the  major  enhancements  are  the  addition  of  Pi,  tables, 
improved  kill  as:essment  modeling,  an  improved  aircraft  flight  model,  infra-red  sensors 
and  IR  vveapon  seekers,  an  enhanced  radar  model,  a  non-graphical  post  processor,  a  new 
ballistic  missile  model,  and  impioved  Monte  Carlo  execution.  These  features  are  designed 
to  add  utility  to  the  model  and  to  make  it  more  user  friendly.  Version  3.00  will  also  be 
compatible  with  the  Sun  Systems  SPARCStation  2  series  workstation  Although  model 
operation  will  be  slightly  different,  the  Sun  compatibility  will  enable  increased  use  of 
EADSIM  at  organizations  without  Silicon  Graphics  equipment 

Another  major  revision  of  EADSIM  is  scheduled  for  December  1993  with  the 
release  of  Version  4.00.  This  release  will  incorporate  new  features  that  were  not  ready 
for  inclusion  into  \G.00.  M^jci  enhancements  of  V4.00  include  electronic  warfare 
improvements,  modeling  of  counterforce,  modeling  of  AAA,  track  management,  air 
tasking,  and  a  database  management  system 

The  follow-on  project  to  EADSIM  is  EADTB.  the  Extended  Air  Defense  Testbed 
It  is  scheduled  for  an  initial  operational  capability  (IOC)  of  October  1993  and  offers  a 
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much  higher  level  of  simulation  and  analysis  capability  over  EADSIM.  EADTB  operates 
on  a  dedicated  main  frame  computer  and  can  receive  inputs  from  EADSIM  and  other 
EADTB  nodes.  Although  EADSIM  was  originally  developed  as  the  EADTB  prototype, 
its  success  has  ensured  that  it  will  continue  to  grow.  It  is  planned  for  EADSIM  and 
EADTB  to  complement  each  other  with  a  compatible  database  management  system. 

B.  CONCLUSIONS 

1.  EADSIM  is  an  Effective  Tool 

EADSIM  is  a  highly  effective  theater  level  model  and  analysis  tool.  Although 
emphasis  is  placed  on  C^I  operations,  it's  versatility  allows  it  to  model  many  aspects  of 
air  warfare  Air-to-surface,  air-to-air,  and  surface-to-air  engagements  may  all  be 
conducted  within  a  simulation  In  addition  EADSIM  can  model  theater  ballistic  missile 
employment  and  theater  ballistic  missile  defense.  It  excels  in  the  simulation  of  a  large 
variety  of  combat  platforms  on  land,  at  sea,  and  in  the  air.  These  platforms  may  be 
modified  by  the  user  to  reach  a  higher  level  of  fidelity,  or  to  model  systems  not  contained 
in  the  EADSIM  library 

EADSIM  is  as  flexible  as  it  is  versatile  The  multiple  run-time  processes  and  the 
Monte  Carlo  execution  allow  the  user  to  easily  simulate  numerous  scenarios.  The  Post 
Processing  reports  provide  the  analyst  wth  a  variety  of  simulation  results.  The  analyst 
may  require  all  the  simulation  results,  or  may  need  to  see  only  a  single  aspect  of  the 
simulation  The  graphical  playback  capability  is  one  of  the  most  outstanding  features  of 
EADSIM  Simulation  results  may  be  viewed  immediately  after  the  completion  of  a 
scenario  run 
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2.  EADSIM  is  a  Complex  Model 

EADSIM  is  a  very  complex  computer  model.  Its  installation  and  operation  require 
the  appropriate  computer  hardware  for  it  to  be  effective.  The  large  and  multiple  data  files 
associated  with  a  simulation  can  become  cumbersome,  particularly  as  a  scenario  grows 
EADSIM  operation  is  not  intuitive,  and  a  high  level  of  experience  is  required  for  user 
p-  -ficiency.  A  working  knowledge  of  UNIX  is  also  necessary  to  troubleshoot  and  debug 
problems  within  the  model  The  learning  curve  on  the  software  is  difficult,  especially  if 
the  user  is  solely  relying  on  the  User's  Manual  and  associated  documentation.  The 
available  (^n-site  training  is  a  necessity  for  a  new  or  first  time  user.  Even  with  user 
experience,  EADSIM  is  not  particularly  user  friendly.  What  appears  to  be  a  successful 
scenario  run  may  not  be  at  all  For  example,  certain  platforms  may  not  properly  employ 
their  weapons,  or  may  not  employ  them  at  all.  This  can  result  in  the  user  having  to  page 
through  numerous  on-screen  menus  to  find  the  source  of  the  problem.  The  final  difficulty 
encountered  is  that  a  scenario  developed  on  one  workstation  may  not  run  on  another.  The 
author  received  a  pre-built  scenario  from  an  outside  source,  but  the  scenario  would  not 
rim  in  the  Visualization  Lab.  Additional  troubleshooting  and  debugging  are  required  for 
this  type  of  problem,  adding  to  the  "user  unfriendliness"  of  the  program. 

Some  of  the  disparities  of  EADSIM  are  not  limited  to  the  actual  hands-on 
operation  of  the  model.  Many  of  the  problems  encountered  are  the  result  of  a  lack  of 
fidelity.  EADSIM  does  not  attempt  to  simulate  all  aspect  of  AAW,  but  simplistic 
modeling  of  real  world  occurrences  can  not  be  considered  as  an  effective  way  of  solving 
problems.  The  single  greatest  flaw  encountered  by  the  author  is  a  lack  of  accurate 
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weapon  modeling.  An  explicit  missile  fly-out  model  may  not  be  necessary,  but  a  single 
probability  of  kill  for  a  weapon  is  not  realistic.  Another  fault  found  by  the  author  is  a 
lack  of  adequate  modeling  of  naval,  specifically  shipboard,  systems.  There  is  not  a  single 
naval  search  radar  or  fire  control  radar  in  the  EADSIM  library.  EADSIM  does  allow  the 
modeling  of  those  systems,  but  the  user  needs  prior  knowledge  of  the  system's  parameters 
to  do  so. 

3.  Upgrades  Will  Correct  Some  Shortcomings 

The  software  changes  being  incorporated  into  EADSIM  Version  3.00  and  Version 
4.00  will  correct  some  of  the  faults  found  in  the  model.  As  the  model  grows  and  evolves 
more  improvements  will  be  made  to  assist  the  user  and  to  attain  higher  levels  of  fidelity. 
In  addition,  more  missions,  platforms,  and  systems  should  find  their  way  into  the  model 
Specific  problems  within  the  software  code  will  continue  to  be  rectified  via  the  Software 
Change  Request.  Each  SCR  is  reviewed  and  a  board  determines  if  the  revision  is  to  be 
included  in  the  next  software  release. 

C.  RECOMMENDATIONS 

1.  Adaptability  for  Student  Use 
a.  UNIX  Training 

In  order  for  a  student  to  become  proficient  in  the  use  of  EADSIM,  they  must 
first  become  adept  in  the  UNIX  operating  system.  The  Computer  Center  offers  a  one 
hour  Introduction  to  UNIX  lesson  several  times  each  quarter.  The  material  given  in  this 
lesson  is  an  overview  is  and  not  sufficient  to  gain  a  working  knowledge  of  UNIX 
Academic  courses  are  offered  from  several  departments  that  deal  with  working  on  UNIX 
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workstations.  These  departments  also  maintain  computer  laboratories  where  students  can 
gain  practical  experience.  The  author  took  the  PH2911  "Computational  Physics"  and 
PH4911  "Combat  Systems  Modeling"  sequence  from  the  Physics  Department.  Both 
courses  provided  an  excellent  overview  on  the  use  of  UNDC,  as  well  as  providing  practical 
experience  on  programming  solutions  to  physical  problems  in  C.  As  stated  in  the 
conclusions,  a  working  knowledge  of  UNIX  is  essential  for  successful  operation  of 
EADSIM. 

b.  EADSIM  Training 

Because  EADSIM  is  such  a  complex  model  and  not  user  friendly,  additional 
training  in  its  operation  is  recommended.  An  EADSIM  User’s  Course  is  sponsored  by 
SSDC  and  offered  by  CAS  Incorporated  and  TBE.  The  two  week  course  may  be 
exported  to  a  command,  or  may  be  held  in  Huntsville,  AL.  Specially  tailored  one  week 
courses  may  be  presented  depending  on  the  user's  needs  and  previous  level  of  experience 
with  the  model.  The  author  recommends  that  if  EADSIM  continues  to  be  used  at  NPS, 
then  an  experienced  user  should  be  on  the  staff  to  assist  and  further  train  student  users. 
This  staff  member  should  take  the  EADSIM  User's  Course  in  Huntsville.  By  taking  the 
course  away  from  NPS,  normal  duties  will  not  detract  from  the  training.  The  staff  user 
should  also  attend  the  EADSIM  User  Group  Conferences  that  are  held  several  times  per 
year.  This  will  ensure  that  NPS  maintains  the  latest  information  and  receives  the  future 
software  releases. 
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2.  Continued  EADSIM  Use  at  NFS 


a.  Computer  Center  Visualization  Laboratory 

The  Visualization  Lab  should  continue  to  maintain  its  status  as  a  registered 
EADSIM  user.  The  SGI  Power  Series  380/VGX  is  equipped  with  the  hard  disk  purchased 
for  this  project  and  has  the  processing  power  to  perform  any  EADSIM  operation.  All 
system  documentation  is  available  in  the  lab  and  other  SGI  workstations  are  aveiilable  for 
use.  Students  with  mainframe  computer  accounts  now  have  access  to  the  Visualization 
Lab.  This  will  allow  the  potential  use  of  EADSIM  at  NFS  by  virtually  any  student  who 
desires.  For  multiple  users,  care  must  be  taken  by  the  system  administrator  concerning 
write  privileges  of  critical  files.  The  Visualization  Lab  has  recently  received  a  new  SGI 
workstation,  the  Indigo' .  It  is  a  top-of-the-line  desktop  system  and  has  the  latest  available 
microprocessor,  the  R4400.  This  workstation  has  equivalent  processing  capability  to  the 
380A^GX  and  could  also  run  any  EADSIM  application.  The  other  SGI  workstations  in 
the  lab  are  older  systems  and  should  be  limited  to  running  smaller  scenarios  and  playback 
files. 

b.  Wargaming  Laboratory 

The  Wargaming  Laboratory  is  a  secure  facility  that  can  run  classified 
simulations  up  to  the  SECRET  level.  A  SECRET  database  is  available  for  EADSIM  and 
could  be  set  up  for  use  in  the  Wargaming  Lab.  The  lab  is  currently  equipped  with  Sun 
SPARCStation  2  workstations  and  could  run  EADSIM  V3.00.  In  addition,  an  SGI  Indigo 
Elan  is  on  order,  equipped  with  the  requisite  24-bit  graphics  plane.  The  Indigo  Elan  has 
nearly  the  same  capabilities  of  the  Indigo'  and  would  be  ideal  for  EADSIM  operation. 
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c.  Installation  In  Other  Computer  Laboratories 


There  are  numerous  other  computer  laboratories  across  the  NFS  campus.  Some 
may  be  suited  for  EADSIM  use.  The  Department  of  Aeronautics  and  Astronautics 
computer  lab  has  ordered  new  Silicon  Graphics  workstations,  three  of  which  will  be 
equipped  with  a  24-bit  graphics  plane.  This  would  be  an  ideal  site  for  EADSIM,  since 
one  of  the  results  of  this  project  was  the  development  of  scenarios  for  AE3705  and 
AE3251.  This  will  also  allow  for  closer  control  over  software  use,  as  open  access  to  this 
lab  is  not  permitted. 

The  Operations  Research  Department  also  has  a  registered  user.  LCDR  Mark 
Rios  is  writing  his  thesis  "Optimum  Aegis  Ship  Stationing  for  Active  Theater  Missile 
Defense"  with  the  assistance  of  EADSIM.  This  department,  unfortunately,  does  not  have 
Silicon  Graphics  or  Sun  computers.  Should  EADSIM  be  further  developed  for  the 
Hewlett  Packard  workstation,  which  is  available  to  Operations  Research  Department 
students  in  Glasgow  Hall,  then  work  could  be  done  there.  Other  curricula  that  could  use 
that  facility  are  National  Security  Affairs  and  Command,  Control,  and  Communications. 

The  Computer  Science  Department  has  its  own  Silicon  Graphics  workstation 
lab.  Much  of  the  work  accomplished  by  students  of  this  curriculum  involves  computer 
programming.  The  EADSIM  source  code  could  be  requested  by  the  department  and 
students  could  perform  source  code  modifications,  perhaps  as  thesis  projects.  Many  of 
the  software  changes  that  appear  in  EADSIM  software  revisions  are  performed  as  site 
modifications  by  other  users. 
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3.  Many  Users 

Because  EADSIM  is  so  versatile  and  because  many  curricula  may  have  a  need  for 
such  a  simulation,  it  is  appropriate  that  the  model  be  maintained  at  f^PS.  The  potential 
for  increased  use  is  such  that  more  sites  at  NPS  could  install  the  model.  The  Air  Force 
Institute  of  Technology  (AFIT)  is  a  registered  user  as  are  numerous  other  defense  research 
agencies.  Although  EADSIM  is  an  Army  project,  it  is  used  jointly  throughout  the 
Department  of  Defense  and  by  many  defense  contractors  Appendix  F  is  a  current  listing 
of  EADSIM  registered  users.  A  powerful  tool  such  as  EADSIM  can  help  get  the  most 
out  of  reduced  research  budgets. 
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APPENDIX  A 


A  Selected  List  of  AAW  and  Air  Defense  Models  and  Simulations 

With  the  exception  of  ACES/Phoenix,  which  is  a  SURVIAC  model,  the  following  list 
of  anti-air  warfare  and  air  defense  models  and  simulations  were  selected  from  the  Defense 
Technical  Information  Center  (DTIC)  Catalog  of  Wargaming  and  Military  Simulation 
Models.  All  model  some  aspect  of  naval  AAW  or  air  defense  and  were  considered  for 
use  in  this  project. 

1.  ACES/Phoenix 

Model  Description:  An  integration  of  several  AAW  simulations  into  a  single 
graphical  interface. 

System  Requirements:  Sun  SPARCStation  or  any  Unix  workstation. 

Operating  System:  UNIX. 

Language:  Various. 

Status:  In  use  at  Air  Force  Operational  Test  and  Evaluation  Center,  Naval 
Postgraduate  School,  Naval  Air  Warfare  Center  Weapons  Division,  Strategic  Joint 
Intelligence  Center. 

2.  Ada  SAM 

Model  Description:  A  surface  to  air  missile  analysis  model  developed  by  the  Air 
Force. 

System  Requirements.  VAX. 
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Operating  System:  VMS. 

Language:  Ada. 

Status:  IOC  1987,  used  by  several  defense  contractors. 

3.  ADMRALS  -  Attack  and  Defense  of  Maritime  Resources  in  Adverse  Locales 
Model  Description:  Developed  by  NSWC  Dahlgren  for  regional  naval  battleforce  and 

fleet  defense  analysis. 

System  Requirements:  Six  Sun  Workstations  for  parallel  processing  and  one  Silicon 
Graphics  Personal  Iris  for  graphics. 

Operating  System;  UNIX. 

Language:  FORTRAN,  Pascal,  C. 

Status;  Funding  ended  FY  '92  before  model  became  operational 

4.  ASBAT  -  Air/Sea  Battle  Model 

Model  Description:  A  multi-threat  Red  on  Blue  engagement  of  naval  vessels  in  open 
ocean  waters  (no  geography). 

System  Requirements:  VAX  or  Sun. 

Operating  System;  VMS  or  UNIX. 

Language:  FORTRAN. 

Status.  IOC  1988,  in  use  at  CINCPACFLT. 

5.  AWSIM  -  Air  Warfare  Simulation 

Model  Description:  Developed  by  Headquarters  U.S.  Armed  Forces  Europe  for 
Air/Land  battle  training.  Limited  naval  applications. 
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System  Requirements;  VAX 
Operating  System.  VMS. 

Language:  FORTRAN.  Ratfor,  C. 

Status.  IOC  1983,  in  use  at  all  NATO  commands. 

6.  COMMANDER  V 

Model  Description:  A  tactical  air,  land,  and  naval  operations  model. 

System  Requirements:  VAX. 

Operating  System;  VMS. 

Language;  FORTRAN,  Simscript  11. 

Status:  IOC  1989,  in  continual  use  and  development  by  Science  Applications 
Applications  Corporation  for  a  variety  of  commercial  and  government  customers. 

7.  COSYCAT  -  Combat  Systems  Capability  Evaluation  Tool 

Model  Description:  Single  ship  surface-to-air  missile  engagement  tool,  designed  to 
evaluate  the  Standard  Missile  (Tartar/SM-1  [MR]). 

System  Requirements:  Hewlett  Packard  9845C. 

Operating  System;  UNIX. 

Language:  HP  Basic. 

Status.  IOC  1987,  no  longer  in  use. 

8.  EADSIM  -  Extended  Air  Defense  Simulation 

Model  Description:  Air,  land,  and  naval  simulation  involving  theater  level  air  defense 
scenarios.  Designed  to  evaluate  force  on  force  outcomes. 


81 


System  Requirements:  Silicon  Graphics  4D  Series  Workstation  (or  higher) 
Operating  System:  UNIX 
Language:  C. 

Status.  IOC  1989,  in  use  by  all  services,  many  contractors,  and  some  allies 

9.  EADTB  -  Extended  Air  Defense  Testbed 

Model  Description:  Follow-on  to  EADSIM,  higher  fidelity  applications  on  mainframe 
computer. 

System  Requirements.  Convex  mainframe. 

Operating  System:  UNIX. 

Language:  C. 

Status:  Under  development,  expected  IOC  October  1993. 

10.  FACTS  -  Fleet  AAW  Model  for  Comparison  of  Tactical  Systems 

Model  Description:  AAW  analysis  model  of  up  to  two  Aircraft  Carriers  in  a  single 
CVBG.  Blue  shipboard  systems  defending  against  Red  ASCM's. 

System  Requirements:  VAX. 

Operating  System:  VMS 
Language:  Pascal. 

Status:  IOC  1983  in  use  at  Naval  Surface  Warfare  Center. 

11.  rWSS  -  Interactive  Weapon  System  Simulation 

Model  Description:  Simulation  of  air,  land,  and  sea  based  weapons  in  offensive  and 
defensive  actions. 
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System  Requirements:  VAX. 

Operating  System:  VMS. 

Language:  Simscnpt  II,  FORTRAN,  DCL. 

Status:  IOC  1989,  used  by  General  Dynamics. 

12.  MARS  -  Multi  Warfare  Assessment  and  Research  System  Model 

Model  Description:  Naval  warfare  model  being  developed  by  NSWC  White  Oak  Lab 
Designed  to  study  the  employment  of  naval  units  operating  in  a  multi-threat  environment 
System  Requirements:  Any  Workstation  (DEC,  HP,  SGI,  SUN,  VAX),  IBM  PC,  or 
Macintosh  11. 

Operating  System:  UNIX,  MS  DOS,  or  System  7. 

Language:  Modsim,  Clips. 

Status:  Not  available,  still  under  development,  expected  IOC  was  Januaiy  1992 

13.  SLAM  -  Ship  Level  Analysis  Model 

Model  Description.  Single  ship  or  single  system  performance  against  AAW  threat 
System  Requirements:  Sun. 

Operating  System:  UNIX. 

Language:  Simscript  II,  Simgraphics. 

Status;  IOC  1990,  in  use  at  Naval  Surface  Weapon  Center. 

14.  THREAT 

Model  Description:  A  battleforce  AAW  model  intended  to  calculate  CVBG 
vulnerability,  recommend  transit  routes  and  determine  CAP  requirements. 
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System  Requirements:  VAX 
Operating  System:  VMS 
Language:  FORTRAN 

Status:  IOC  1989,  in  use  at  CINPACFLT,  Naval  Ocean  Systems  Center 
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APPENDIX  B 


EADSIM  User's  Group  Lessons  Learned 

The  most  recent  EADSIM  User’s  Group  conference  was  held  23  -  25  February  1993 
at  Teledyne  Brown  Engineering  in  Huntsville,  Alabama.  The  author  was  in  attendance. 
During  the  three  day  seminar,  a  variety  of  topics  were  presented  by  several  contractors 
and  representatives  of  all  military  branches.  Of  note,  however,  was  a  marked  lack  of 
Navy  participation  at  the  User's  Group.  Of  the  nearly  one  hundred  attendees,  only  two 
had  Navy  affiliation.  Largely,  the  Army  and  the  Air  Force  have  had  the  strongest  interest 
in  EADSIM. 

Most  of  the  presentations  concerned  recent  analysis  work  done  with  EADSIM.  Others 
covered  new  modifications  to  the  software  that  may  make  their  way  into  the  baseline 
code.  Interfaces  with  other  simulations  and  simulators  were  presented.  These  were 
relevant  in  that  they  addressed  EADSIM  as  a  training  aid  rather  than  an  analysis  tool. 
Advanced  training  aids  may  come  to  the  forefront  as  training  budgets  shrink.  EADSIM 
has  shown  the  potential  to  be  one  of  them. 

The  Extended  Air  Defense  Testbed  (EADTB)  was  briefed  by  the  Army  Space  and 
Strategic  Defense  Command  Testbed  Product  Office.  The  presentation  not  only  stressed 
the  evolution  of  EADSIM  into  EADTB,  but  also  that  EADSIM  use  will  continue  to  be 
important  to  provide  data  for  EADTB  use.  Despite  the  arrival  of  EADTB  later  this  year, 
EADSIM  will  continue  to  grow.  The  maturity  of  EADSIM  and  the  continuous 
improvement  of  the  model  have  made  it  a  favorite  among  its  users. 
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The  most  controversial  topic  of  the  User's  Group  meeting  was  the  Joint  Air  Defense 
Operations  and  Joint  Engagement  Zone  Office  (JADO/JEZ)  briefing  on  Verification, 
Validation  and  Accreditation  (VV&A).  The  JADO/JEZ  Office  has  done  limited  work  on 
verifying  certain  aspects  of  the  EADSIM  code.  This  effort  has  been  rejected  by  some 
who  state  that  VV&A  is  equivalent  to  a  mathematical  proof  of  the  model's  accuracy.  Of 
course,  such  a  measure  is  impossible  for  a  code  as  complex  as  EADSIM.  Others  see 
VV&A  as  a  measure  that  makes  the  model  acceptable.  Although  JADO/JEZ  has  tried  to 
verify  and  validate  some  of  the  logic  in  the  software,  JADO/JEZ  will  not  attempt  a 
complete  validation  of  EADSIM. 

The  next  User's  Group  is  scheduled  to  meet  in  June  1993  to  coincide  with  the  release 
of  EADSIM  Version  3.00.  It  has  been  a  traditional  practice  to  hold  the  conference 
concurrent  with  the  release  of  a  new  version  of  the  code.  EADSIM  Version  4.00  is 
planned  for  release  in  December  1993. 
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APPENDIX  C 


EADSIM  Scenario  Guide 

The  following  is  a  guide  for  students  enrolled  in  AE3705  "Air  Defense  Lethality"  and 
AE3251  "Aircraft  Combat  Survivability".  Scripted  scenarios  have  been  developed  for 
use  in  these  courses  and  are  currently  available  on  the  Silicon  Graphics  workstations  of 
the  Computer  Center  Visualization  Laboratory.  The  scenarios  have  been  pre-run  such  that 
they  require  only  access  of  the  playback  files  and  no  previous  experience  with  EADSIM. 
Consult  the  EADSIM  User's  Guide  (Appendix  D)  for  specific  operational  procedures  to 
view  these  scenarios  on  the  Silicon  Gr^hics  workstations  of  the  Visualization  Lab. 
Students  who  desire  further  information  on  the  model  may  consult  the  EADSIM  manuals 
which  are  available  in  the  Visualization  Lab.  By  viewing  the  scenario  playback  files,  die 
student  can  see  the  cause  and  effect  of  several  aspect  of  AAW. 

1.  Naval  AAW  Scenarios 

This  set  of  scenarios  have  been  developed  for  AE  3705  and  are  designed  to  represent 
the  air  defense  of  naval  forces  operating  in  littoral  waters.  The  ships  are  operating  in  the 
eastern  Mediterranean  Sea  off  the  coast  of  Lebanon.  The  threat  is  a  combination  of  anti¬ 
ship  cruise  missiles  (ASCM's),  both  shore  launched  and  air  launched,  and  tactical  attack 
aircraft.  The  ASCM's  are  are  of  the  Silkworm  family,  the  shore  launched  missiles  being 
launched  from  Transporter  Erector  Launchers  (TEL's)  and  the  air  launched  missiles  bieng 
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launched  from  Tu-16  Badger  bombers.  In  addition,  MiG-23  Flogger  attack  aircraft  armed 
with  standoff  weapons  and  gravity  bombs  are  also  ready  for  attack. 

The  first  scenario  run  (AAW_1)  has  a  Ticonderoga  (CG-47)  class  guided  missile 
cruiser  operating  autonomously  in  the  vicinity  of  the  threat.  The  Aegis  cruiser  is 
equipped  with  the  AN/SPY- 1  phased  array  radar  and  the  SM-2  Standard  Missile.  All 
sensors  are  operational  and  all  launchers  are  loaded.  The  second  scenario  adds  a 
Spruance  (DD-963)  class  destroyer  operating  with  the  cruiser.  This  ship's  sensors  are 
limited  to  two-dimensional  air  search  radars  and  it  is  equipped  with  the  NATO 
SeaSparrow  (RIM-7)  point  defense  missile  system.  This  second  scenario  is  run  twice, 
with  the  first  run  (AAW_2)  having  the  ships  operate  independently.  The  second  run  of 
this  scenario  (AAW_3)  gives  tactical  control  of  both  ship's  weapon  systems  to  the  cruiser. 
This  represents  the  use  of  tactical  data  links  and  a  command  and  control  structure.  The 
third  scenario  adds  an  aircraft  carrier  to  be  protected  against  the  incoming  threat.  The 
organic  assets  of  the  carrier,  its  aircraft  and  point  defense  systems,  are  not  not  available 
for  use.  Two  runs  of  this  scenario  are  conducted;  one  ivith  tactical  control  on  the  cruiser 
(AAW_4),  and  the  other  with  tactical  control  on  the  carrier  (AAW_5). 

2.  Naval  Strike  Aircraft  Scenarios. 

These  scenarios  have  been  developed  developed  for  AE  3251  and  simulate  an  aircraft 
strike  against  defended  targets.  The  targets  in  this  set  of  scenarios  are  airfields  in  the 
vicinity  of  Beirut.  They  are  defended  by  an  integrated  network  SAM's  consisting  of  SA-8 
and  SA-11  batteries.  The  SAM  batteries  are  also  supported  by  ground  based  early 
warning  radars. 
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The  first  scenario  (Air_Strike_l)  is  an  unprotected  raid  on  the  airfields  by  two  flights 
of  eight  F/A-18  Hornets.  The  attack  fighters  are  aimed  with  only  gravity  bombs.  In  the 
second  run  of  this  scenario  (Air_Strike_2),  the  attacking  aircraft  are  given  stand-off 
weapons  to  avoid  exposure  to  the  SAM  envelope.  The  third  run  of  the  scenario 
(Air_Strike_3)  adds  stand-off  jamming  and  anti-radiation  missiles.  An  EA-6B  Prowler 
is  provided  for  jamming  services  and  two  A-6E  Intruders  are  added  to  each  flight  armed 
with  the  High-speed  Anti-radiation  Missile  (HARM).  The  fourth  run  (Air_Strike_4)  puts 
Defensive  Counter  Air  in  the  form  of  MiG-29  Fulcrum  and  MiG-25  Foxbat  fighters  up 
against  the  strike.  The  enemy  CAP  also  has  support  of  ground  control  intercept  (GCI) 
radar.  The  fifth  scenario  run  (Air_Strike_5)  adds  escort  fighters  to  the  strike  package. 
In  this  case,  two  sections  of  F-14  Tomcats  provide  cover  against  the  enemy  fighters. 
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APPENDIX  D 


EADSIM  Visualization  Lab  User's  Guide 

This  guide  is  designed  for  use  by  AES 70 5  "Air  Defense  Lethality"  and  AE3251 
"Aircraft  Combat  Survivability"  students  for  the  scenarios  described  in  Appendix  C.  The 
playback  files  for  the  scenarios  are  available  for  viewing  on  the  Silicon  Graphic^ 
workstations  of  the  Computer  Center  Visualization  Laboratory.  Students  must  obtain  a 
mainframe  account,  the  log  in  for  the  Visualization  Lab  uses  the  same  password  as  the 
mainframe.  The  following  procedure  will  take  a  student  through  the  appropriate  menus 
so  that  the  scenario  playback  files  can  be  viewed. 

Procedure: 

1.  Log  on  to  any  SGI  workstation. 

2.  From  the  IRIX  window  environment,  with  left  mouse  button,  click  on  Programs. 

3.  From  Program  window,  with  left  mouse  button,  click  on  EADSIM  Training. 

4.  Wait  for  program  to  load. 

5.  Hold  right  mouse  button,  note  menu  bar  at  top  of  display. 

6.  Drag  cursor  to  Applications  without  lifting  on  right  mouse  button. 

7.  Continue  to  drag  down  to  highlight  Scenario  Playback,  lift  right  mouse  button. 

8.  Wait  for  Scenario  Playback  Application  to  load. 

9.  From  the  scenario  playback  window,  hold  right  mouse  button,  note  new  menu  bar  at 
top  of  display.  Scenario  Playback  window  must  be  active  to  get  the  new  menu.  NOTE: 
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An  active  window  is  bordered  in  red.  To  activate  a  window,  click  the  left  mouse  button 
with  the  cursor  inside  the  window. 

10.  With  right  mouse  button,  drag  to  Scenario  Playback  without  lifting  . 

11.  Continue  to  drag  down  to  highlight  Load  Playback  File,  lift  right  mouse  button. 

12.  From  Start  Playback  window,  select  appropriate  directory  (AE3705  or  AE3251). 

13.  With  left  mouse  button,  click  on  appropriate  directory. 

14.  Note  highlighted  title  name  and  playback  file  name  at  bottom  of  window  (they 
should  be  the  same). 

15.  With  left  mouse  button,  click  on  Select. 

16.  From  Start  Playback  window,  select  title  of  scenario  nm  to  be  viewed; 

AAW_1  Air_Strike__l 

AAW_2  Air_Strike_2 

AAW_3  Air_Strike_3 

AAW_4  Air_Strike_4 

AAW_5  Air_Strike_5. 

17.  With  left  mouse  button,  click  on  appropriate  scenario  title. 

18.  Note  highlighted  playback  file  and  playback  file  name  at  bottom  of  window  (they 
should  be  the  same). 

19.  With  left  mouse  button,  click  on  Select. 

20.  Wait  for  computer  to  build  map. 

21.  When  map  is  built,  note  control  panel  window  at  top  right  comer  of  display. 

22.  With  left  mouse  button,  click  on  Run. 
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23  View  scenario  playback. 

24.  To  hold  playback  file,  click  on  Pause  with  left  mouse  button. 

25.  To  increase  playback  speed,  click  on  the  "  +  "  token  with  the  left  mouse  button. 

26.  To  slow  playback  speed,  click  on  the  "  -  ”  token  with  the  left  mouse  button. 

27.  To  fast  forward  to  the  end  of  the  playback  file,  click  on  the  "  FF  "  token. 

28.  Once  viewing  is  complete,  click  on  Rerun  to  view  again,  or  click  on  Abort  to  finish. 

29.  To  load  and  view  another  file,  follow  procedure  from  step  10 

30.  To  exit  Scenario  Playback;  hold  right  mouse  button  and  drag  cursor  to  Scenario 
Playback,  without  lifting,  drag  down  to  Quit,  drag  right  to  Confirm,  lift  right  mouse 
button. 

31.  To  exit  EADSIM,  hold  right  mouse  button  and  drag  cursor  to  Applications,  without 
lifting,  drag  down  to  End  EADSIM  Session,  drag  right  to  Confirm,  lift  right  mouse 
button. 

32.  To  log  off  SGI  workstation,  hold  left  mouse  button,  drag  to  Log  Off,  lift  left  mouse 
button. 

33.  Click  on  Yes  with  left  mouse  button  to  confirm. 
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APPENDIX  E 


EADSIM  Post  Processing  Reports 

The  following  is  an  excerpt  from  a  computer  generated  output  file  from  the  EADSIM 
Post  Processor.  These  reports  are  from  a  scenario  run  of  the  Naval  AAW  scenario 
discussed  in  Chapter  IV,  Chapter  V,  Appendix  C,  and  Appendix  D.  It  is  a  history  report, 
and  gives  a  chronological  listing  of  events  that  occurred  during  Scenario  Execution.  The 
actual  report  is  approximately  150  pages  in  length,  therefore,  it  is  not  included  in  it's 
entirety. 
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*  * 


00:00:00.000 


Beginning  execution. . .  ** 

CG-47.1  activated  at  time 
ENGAGE:  CG-47.1  activated 

SILKWORML1.5  activated  at  time  -  00:00:00.000 
ENGAGE:  SILKWORM_1.5  activated 
BADGER_1.8  activated  at  time  -  00:00:00.000 
ENGAGE:  BADGER_1 . 8  activated 
BADGER_2.9  activated  at  time  -  00:00:00.000 
ENGAGE:  BADGER_2 . 9  activated 

SILKWORM_2 . 10  activated  at  time  -  00:00:00.000 
ENGAGE:  SILKWORM_2 . 10  activated 
RED_BASE.11  activated  at  time  -  00:00:00.000 
ENGAGE:  RED_BASE.11  activated 

SILKWORM_3 . 12  activated  at  time  -  00:00:00.000 
ENGAGE:  SILKWORM_3 . 12  activated 

RED_ATTACK_4. 13  activated  at  time  -  00:00:00.000 
ENGAGE:  RED_ATTACK_4 . 13  activated 
RED_ATTACK_5 . 14  activated  at  time  -  00:00:00.000 
ENGAGE:  RED_ATTACK_5 . 14  activated 
RED_ATTACK_6. 15  activated  at  time  -  00:00:00.000 
ENGAGE:  RED_ATTACK_6 . 15  activated 
STRIKE_1.16  activated  at  time  -  00:00:00.000 
ENGAGE:  STRIKE_1.16  activated 
DD-963.17  activated  at  time  -  00:00:00.000 
ENGAGE:  DD-963.17  activated 

RED_STRIKE_1.18  activated  at  time  -  00:00:00.000 
ENGAGE:  RED_STRIKE_1 . 18  activated 
1  3  1  8  7  0 

IFF:  CG-47.1  vs  BADGER_1.8:  unknown  by  first  scan  rule 
IFF:  Target  BADGER_1.8  is  squawking. 

IFF:  CG-47.1  vs  BADGER_.1.8:  unknown  by  interrogation  of  enemy 
TRK:  CG-47.1  initiated  track  on  BADGER_1.8. 

1  3  1  15  7  0 

IFF:  CG-47.1  vs  RED_ATTACK_6. 15:  unknown  by  first  scan  rule 
IFF:  Target  RED_ATTACK_6 . 1 5  is  squawking. 

IFF:  CG-47.1  vs  RED_ATTACK_6 . 15 :  unknown  by  interrogation  of  enemy 
TRK:  CG-47.1  initiated  track  on  RED_ATTACK_6. 15. 

1  31  13  7  0 

IFF:  CG-47.1  vs  RED_ATTACK_4 . 13 :  unknown  by  first  seem  rule 
IFF:  Target  RED_ATTACK_4 . 13  is  squawking. 

IFF:  CG-47.1  vs  RED_ATTACK_4 . 13 :  unknown  by  .nterrogation  of  enemy 
TRK;  CG-47.1  initiated  track  on  RED_ATTACK_4 . 13 . 

1  3  1  9  7  0 

IFF:  CG-47.1  vs  BADGER_2.9:  unknown  by  first  scan  rule 
IFF;  Target  BADGER_2 . 9  is  squawking. 

IFF:  CG-47.1  vs  BADGER_2.9:  unknown  by  interrogation  of  enemy 
TRK:  CG-47.1  initiated  track  on  BADGER_2.9. 

1  31  18  7  0 

IFF:  CG-47.1  vs  RED_STRIKE_1 . 18;  unknown  by  first  scan  rule 
IFF;  Target  RED_STRIKE_1 . 18  is  squawking. 

IFF:  CG-47.1  vs  RED_STRIKE_1 . 18 ;  unknown  by  interrogation  of  enemy 
TRK;  CG-47.1  initiated  track  on  RED_STRIKE_1.18. 

14  3  1  13  6  0 

IFF:  RED_ATTACK_5 . 14  vs  RED_ATTACK_4 . 13 :  friendly  by  first  scan  rule 
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■*  * 


Interval  Advanced,  Scenario  Time:  00:00:03.000 
00:00:05.837  -  ASl  :  RED_ATTACK_5 . 14 
1  6  1  8  7  0 

IFF:  CG- 47.1  vs  BADGER_1.8:  unknown  by  interrogation  of  enenv 
TRK:  CG-47.1  updated  track  on  BADGER_1.8. 

1  61  15  7  0 

IFF:  CG-47.1  vs  RED_ATTACK_6 . 15 :  unknown  by  interrogation  of  enemy 
TRK:  CG-47.1  updated  track  on  RED_ATTACK_6 . 15. 

1  61  13  7  0 

IFF:  CG-47.1  vs  RED_ATTACK_4 . 1 3 :  unknown  by  Interrogation  of  enemy 
TRK:  CG-47.1  updated  track  on  RED_ATTACK_4. 13 . 

1  6  1  9  7  0 

IFF:  CG-47.1  vs  BADGER_2 . 9 :  unknown  by  interrogation  of  enemy 
TRK:  CG-47.1  updated  track  on  BADGER_2.9. 

1  61  18  7  0 

IFF:  CG-47.1  vs  RED_STRIKE_1 . 18 :  unknown  by  interrogation  of  enemy 
TRK:  CG-47.1  updated  track  on  RED_STRIKE_1. 18. 

14  6  1  13  7  0 


**  Interval  Advanced,  Scenario  Time:  00:00:06.000  ** 


00:00:08.000  -  FSAMl;  CG-47.1 
00:00:08.435  -  ASl  :  RED_STRIKE_1 . 18 
1  9  1  8  7  0 

TRK:  CG-47.1  updated  track  on  BAiy'ER_1.8. 

1  91  15  7  0 

TRK;  CG-47.1  updated  track  on  RED_ATTACK_6. 15. 
1  9  1  13  7  0 


TRK:  CG-47.1  updated  track  on  RED_ATTACK_4. 13 . 
1  9  1  9  7  0 


TRK:  CG-47.1  updated  track  on  BADGER_2.9. 

1  91  18  7  0 

TRK;  CG-47.1  updated  track  on  RED_STRIKE_1. 18. 


14  9  1 

13  7  0 

**  Interval  Advanced, 

Scenario  Time: 

00:00:09.000 

-  FSAMl: 

CG-47.1 

00:00:09.359 

-  ASl  : 

BADGER_1 . 8 

00:00:09.621 

-  ASl  ; 

BADGER_2 . 9 

00:00:10.000 

-  FSAMl: 

CG-47.1 

00:00:11.000 

-  FSAMl: 

CG-47.1 

00:00:11.160 

-  ASl  : 

RED_ATTACK_6 . 15 

*  * 


RED_ATTACK_1 . 2  activated  at  time  -  00:00:11.999 
ENGAGE:  RED_ATTACK_1 . 2  activated 
1  12  1  870 


TRK;  CG-47.1  updated  track  on  BADGER_1.8. 

1  12  1  14  7  0 

IFF:  Target  RED_ATTACK_5 . 14  is  squawking. 

IFF:  CG-47.1  vs  RED_ATTACK_5 . 14 :  unknown  by  interi  ition  of  enemy 
TRK:  CG-47.1  initiated  track  on  RED_ATTACK_5. 14 . 

1  12  1  15  7  0 

TRK:  CG-47.1  updated  track  on  RED_;.TTACK_6. 15. 

1  12  1  13  7  0 

TRK:  CG-47.1  updated  track  on  RED_ATTACK_4. 13 . 

1  12  1  970 

TRK:  CG-47.1  updated  track  on  BADGER_2.9. 

1  12  1  2  7  0 
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APPENDIX  F 


The  following  list  of  registered  EADSIM  users  was  provided  by  the  U.S.  Army 
Missile  Command  (MICOM)  EADSIM  User  Services  Office.  It  lists  all  currently 
registered  EADSIM  users  as  of  26  May  1993^  the  point  of  contact  for  the  organization, 
and  their  address.  The  EADSIM  User  Services  Office  maintains  the  user  database  and 
updates  it  continuously. 
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1 

32ND  AAOCOM 

POC:  COL  STONE 

Addr;  COMMANDER 

32D  AADCOM 

ATTN  AETL-GC-PL  (MAJ  WILSON) 

APO  NY  09175 

2 

AERONAUTICAL  SYSTEMS  CENTER,  DEVELOPMENT  PLANNING 

POC:  TONY  KIM 

Addr  .  ASC/XREC 

BLDG11A 

1970  3RD  STREET  SUITE  2 

ATTN  TONY  KIM 

WPAFB  OH  45433-7209 

3 

AERONAUTICAL  SYSTEMS  CENTER  -  ELECTRONIC  COMBAT  SYSTEMS  PROGRAM  OFFICE 

POC:  WILUAM  E.  LYONS 

Addr:  ATTN  WILLIAM  E.  LYONS 

ASC/RWXE  BLDG  28 

2145  THIRD  STREET 

WRIGHT  PATTERSON  AFB,  OH  45433-7017 

4 

AERONAUTICAL  SYSTEMS  CENTER/RANGE  SYSTEMS  PROGRAM  OFFICE 

POC:  Capt  Tom  Connare 

Addr:  ATTN  CAPT  CONNARE 

ASCA'IEJ 

EGUNAFB  FL  32540 

5 

AFIT/ENG 

POC:  Dr.  Thomas  Hartrum 

Add-:  AFIT/ENG 

ATTN  TOM  HARTRUM 

WRIGHT-PATTERSON  AFB  OH  45433-6583 

6 

AFSAA/SAG 

POC:  Lt  Col  Frederic  T  Case 

Addr:  AFSAA/SAG 

ROOM  1 D380  (LT  COL  CASE) 

PENTAGON 

WASHINGTON  DC  20330 

7 

AIR  DEFENSE  LIASON  TEAM 

POC:  LTC  Anderson 

Addr:  AIR  DEFENSE  LIASON  TEAM  KOREA 
(FKJ3-OP-ADA)  UNIT  NUMBER  15237 

APO  AP  96205-0010 

ATTN  LTC  ANDERSON 

8 

AIR  FORCE  ELECTRONIC  WARFARE  CENTER  -  VULNERABILITY  ANALYSIS  DIVISION  (SAV) 

POC:  Capt  Troy  Caudle 

Adcfr:  AFEW  ;/SAV 

ATTN  CAPT  CAUDLE 

3AN  ANTONIO  TX  78243-5000 

9 

AIR  FORCE  WARGAMING  CENTER 

POC:  Mr.  Kenneth  E.  Lavoie 

Addr:  AUCADRE/WG 

ATTN  KEN  LAVOIE 

BLDG  1406 

MAXWELL  AFB  AL  361 12-5532 
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10  AlWS  PROJECT  OFFICE  NAVAL  AIR  WARFARE  CENTER  -  WEAPONS  DIVISION 

POC:  Dale  Knutsen 

Add-:  COMMANDER  (CODE  C28P) 

NAVAL  AIR  WARFARE  CENTER  -  WEAPONS  DIVISION 
ATTN  DALE  KNUTSEN 
CHINA  LAKE  CA  9355S8001 


11  ARINC  RESEARCH  CORPORATION 
POC:  Bizabelh  Thomson 
Addr  ARINC  RESEARCH  CORPORATION 
2551  RIVA  ROAD 
ATTN  ELIZABETH  THOMSON 
ANNAPOLIS  MD  21401 


12  ARL 


POC:  MAJ  MacAllister 
Addr.  ARMY  RESEARCH  LAB 

ATTN  AMSRL-WT-WA  (MAJ  MACALLISTER) 
APGMD  21005-5066 


13  ARMSTRONG  UB  HUMAN  ENGINEERING  -  WRIGHT  PATTERSON  AFB 
POC:  Gilberl  Kupperman 
Addr:  AUCFHl 

ATTN  GILBERT  KUPPERMAN 
WRIGHT-PATTERSON  AFB  OH  45433-6573 


14  ASI 


POC:  Michelle  Kilikauskas 
Addr  ASI 

ATTN  MICHELLE  KlUKAUSKAS 
825  NORTH  DOWNS 
RIDGECREST  CA  93555 


15  BATTELLE  MEMORIAL  INSTITUTE 
POC:  Fred  Rea 

Addr:  BATTELLE  MEMORIAL  INSTITUTE 
505  KING  AVENUE 
ATTN  FRED  REA 
COLUMBUS  OH  43201-2693 


16  BDM 


POC'  Margaret  Dellinger 
Addr:  BDM  INTERNATIONAL  INC 
950  EXPLORER  BLVD 
ATTN  MARGARET  DELLINGER 
HUNTSVILLE  AL  35806 


17  BOEING  AEROSPACE  AND  ELECTRONICS 
POC  Gene  Bnjce 

Addr:  BOEING  DEFENSE  AND  SPACE  GROUP 
ATTN  GENE  BRUCE 
POBOX3999 
MAIL  STOP  8Y-61 
SEATTLE,  WA  98124-2499 


18  BOOZ  ALLEN 

POC'  Ben  Johnson 
Addr  BOOZ  ALLEN 

ATTN  BEN  JOHNSON 
1525  PERIMETER  PARKWAY 

ct  ||*rc  qrjf) 

HUNTSVILLE  AL  35806-1685 
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19  BCX>2  ALLEN  &  HAMILTON  INC.  “ 

POC:  Michael  P.  Slrombefg 
Addr:  BOOZ  ALLEN  &  HAMILTON  INC 
ATTN  MICHAEL  P  STROMBERG 
8283  GREENSBORO  DRIVE 
ROOM  635 
MCLEAN  VA  22102 


20  CAE-UNK 

POC:  Dennis  Miller 

Addr:  LINK  FLIGHT  SIMULATION  DIVISION 
PO  BOX  1237 
ATTN  DENNIS  MILLER 
BINGHAMTON  NY  13902 


21  CAS.  INC 

POC:  Fred  Sharp 
Addr  CAS  INC 

650  DISCOVERY  DRIVE 
PO  BOX  11190 
ATTN  FRED  SHARP 
HUNTSVILLE  AL  35814 


22  CENTER  FOR  NAVAL  ANALYSIS 
POC:  Peter  Dezendorf 
Addr  CENTER  FOR  NAVAL  ANALYSIS 
ATTN  PETER  DEZENDORF 
4401  FORD  AVENUE 
ALEXANDRIA  VA  22302 


23  CENTRAL  INTELLIGENCE  AGENCY 
POC:  Thomas  Donahue 
Addr:  CIA/OSWR 

ATTN  TOM  DONAHUE 
WASHINGTON  DC  20505 


24  CINCPAC  FLT 

POC:  Dr.  Ray  Runyan 

AddT:  COMMANDER  IN  CHIEF  UNITED  STATES  PACIFIC  FLEET 
ATTN  DR.  RAY  RUNYAN 
POBOX6 

BLDG  250  ROOM  202  CODE  N53 
PEARL  HARBOR  HI  96860-7000 


25  COLSA 


POC:  Donna  Painter 
Addr:  COLSA  CORPORATION 
ATTN  DONNA  PAINTER 
6726  ODYSSEY  DRIVE 
HUNTSVILLE  AL  35806 


26  CORPS  SURFACE-TO-AIR  MISSILE  PROJECT  MANGAGEMENT  OFFICE 
POC;  BOB  SHACKELFORD 
Addr:  PROGRAM  EXECUTIVE  OFFICE 

GLOBAL  PROTECTION  AGAINST  LIMITED  STRIKES 
ATTN  SFAE-GPL-SM-E(SHACKELFORD) 

P  O.  BOX  1500 

REDSTONE  ARSENAL  AL  35807-3801 


27  CRC 


POC:  Krista  Givens 

Addr:  COLEMAN  RESEARCH  CORPORATION 
6820  MOOUIN  DRIVE 
ATTN  KRISTA  GIVENS 
HUNTSVILLE  AL  35806 
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POC:  Jackie  Rose 

Ad*:  COLEMAN  RESEARCH  CORPORATION 
990  EXPLORER  BLVD 
SUITE  A 

ATTN:  JACKIE  ROSE 
HUNTSVILLE  AL  35806 


29  DARPA 


POC:  James  T.  Silverthom 
Addr:  DARPA/ADI 

ATTN  JAMES  SILVERTHORN 
4001  NORTH  FAIRFAX  DRIVE 
CEXEC  SUITE  410 
ARUNGTONVA  22203 


30  DCSOPS 

POC:  Dan  Cunningham 

Addr.  DEPARTMENT  OF  THE  ARMY 

DEPUTY  CHIEF  OF  STAFF  FOR  OPERATIONS  AND  PLANS  (DAMO-MOIA) 
PENTAGON  (ATTN  DAN  CUNNINGHAM) 

WASHINGTON  DC  20310-0410 


31  DECISION  SCIENCE  APPLICATIONS 
POC:  Kathie  Reece 
Addr.  ATTN  KATHIE  REECE 
1755TELSTAR  RD 
SUITE  201 

COLORADO  SPRINGS  CO  80920 


32  DESE  RESEARCH,  INC. 

POC:  Frederick  W.  Chiverton 
Addr  DESE 

ATTN  FREDERICK  CHIVERTON 
2700TRIANA  BLVD 
HUNTSVILLE  AL  35805 


33  DET4,  USAFAWC 

POC:  Lt  Kevin  Nyberg 
Addr:  DETACHMENT  4 

USAF  AIR  WARFARE  CENTER 
ATTN  LT  NYBERG 
BLDG  20361 

KIRTLAND  AFB  NM  87117-5617 


34  DIA 


POC:  Bill  Flemming 
Addr:  DIAC(DB-1/PMO) 

ATTN:  BILL  FLEMMING 
BOLLING  AIR  FORCE  BASE 
WASHINGTON  DC  20340-6575 


35  DIO 

POC:  Dan  Haggerty 
Addr:  DIO 

ATTN  ECAC/IITRI(HAGGERTY) 

185  ADMARAL  COCHERANE  DRIVE 
ANNAPOLIS  MD  21401 


36  DYNETICS,  INC. 

POC:  Bill  Haines 
Addr  DYNETICS  INC 
PO  DRAWER  B 
ATTN  BILL  HAINES 
HUNTSVILLE  AL  35814-5050 
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37 

EL  PASO  ANALYTICS 

POC:  Steven  Chavez 

Addr;  EL  PASO  ANALYTICS 

ATTN  STEVEN  CHAVEZ 

7750  ALABAMA  ST  *8 

EL  PASO  TX  79904-3136 

38 

ELECTROSPACE  SYSTEMS 

POC:  G-  V.  McWilliams 

Ad*:  ELECTROSPACE  SYSTEMS 

PO  BOX  831359 

ATTN  MAIL  STATION  2800  (G  V  MCWILLIAMS) 

RICHARDSON  TX  75083-1359 

39 

FASTC 

POC:  CAPT  ROBERT  COLLINS 

Add^:  FASTC/TAAE 

ATTN  CAPT  ROBERT  COLLINS 

WRIGHT-PATTERSON  AF8  OH  45433-6508 

40 

FLIGHT  CONTROL  DIVISION 

POC:  Jack  Barry 

AddrWL/FIGS 

ATTN  JACK  BARRY 

WPAFB  OH  45433-6553 

41 

GENERAL  DYNAMICS  -  CONVAIR 

POC:  Bob  Stewart 

Addr:  HUGHES  AIRCRAFT  CORP  -  MISSILE  SYSTEMS  DIV 

ATTN:  BOB  STEWART  M2  3&^0O0 

PO  BOX  85357 

SAN  DIEGO  CA  92138 

42 

GENERAL  RESEARCH  CORPORATION 

POC:  Tom  Chapman 

Ad*:  GENERAL  RESEARCH  CORPORATION 

635  DISCOVERY  DRIVE 

ATTN  TOM  CHAPMAN 

HUNTSVILLE  AL  35806 

43 

GENERAL  RF'''=ARCH  CORPORATION 

POC:  Biondan  Callahan 

Ad*:  GENERAL  RESEARCH  CORPORATION 

ATTN  BRENDAN  CALLAHAN 

1900  GALLOWS  ROAD 

VIENNA  VA  22182 

44 

GEO  DYNAMICS 

POC:  Pam  Littleton 

Ad*:  GEO  DYNAMICS 

ATTN  PAM  LITTLETON 

5450  TECH  CENTER  DRIVE  #230 

COLORADO  SPRINGS  CO  80919 

45 

GEORGIA  TECH  RESEARCH  INSTITUTE 

POC:  James  Green 

Ad*:  GTRI/HRL 

PO  BOX  91 62 

ATTN  JIM  GREEN 

HUNTSVILLE  AL35812-0162 
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46  HQAFOTC 

PCX^;  Capt  Venton  Duncan 
Addr.  HQAFOTC /SAN 
ATTN  CAPT  DUNCAN 
8500  GIBSON  BLVD 
KIRTLANDAFB  NM  871 17-5558 


47  HUGHES  AIRCRAFT  COMPANY  -  LA. 

POC:  Jim  Soash 

Addr.  HUGHES  AIRCRAFT  COMPANY 
ATTN  JIM  SOASH 
PO  BOX  45066 

LOS  ANGELES  CA  9004&0066 


48  IITRI 


POC:  Darra  Frost 
Addr.  ECAC/IITRI 

185  ADMIRAL  COCHRAN  DRIVE 
ANNAPOLIS  MD  21401 


49  JBL  COX  ENTERPRISES 
POC:  Jerry  Cox 
Addr:  JBL  COX  ENTERPRISES 
9  LAKE  LORRAINE  CIRCLE 
ATTN  JERRY  COX 
SHAUMAR  FL  32579 


50  JOHN  HOPKINS  UNIVERSITY 
POC:  Lou  Gieszel 

Addr  JOHN  HOPKINS  UNIVERSITY 
APPUED  PHYSICS  LAB 
ATTN  LOU  GIESZEL 
JOHN  HOPKINS  ROAD 
LAUREL  MD  207230099 


51  JOINT  STAFF  -  FORCE  STRUCTURE,  RESOURCES  AND  ASSESSMENT 
POC:  LCDR  LIZ  STERNAMAN 
Addr:  THE  JOINT  STAFF 

ATTN  LCDR  STERNAMAN 
ASD/ROOM  1D929 
THE  PENTAGON 
WASHINGTON  DC  20318-8000 


52  LAWRENCE  LIVERMORE  NATIONAL  L^BORATORY 
POC  Al  Kaufman 

Ad*;  LAWRENCE  LIVERMORE  NATIONAL  LABORATORY 
ATTN:  DR.  ALFRED  M.  KAUFMAN 
MSL-85 

7000  EAST  AVENUE 
LIVERMORE,  CA  94550 


53  LOCKHEED  AERONAUTICAL  SYSTEMS  COMPANY 
POC:  M.  R.  Doody 

Addr:  LOCKHEED  AERONAUTICAL  SYSTEMS  COMPANY 
ATTN  M.  R.  DOODY 
86  SOUTH  COBB  DRIVE 
DEPT  73-D4  ZONE  0685 
MARIETTA  GA  30063 


54  LOCKHEED,  FT  WORTH 

POC  Anthony  D.  Lewis 
Addr:  LOCKHEED,  FT  WORTH 
PO  BOX  748 

ATTN  ANTHONY  D.  LEWIS 
FT  WORTH  TX  76101 
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55  LOCKHEED  MISSILES  AND  SPACE 
POC:  Df.  Ed  Dobbins 

Addr:  LCX:KHEED  MISSILES  AND  SPACE 
ATTN:  ED  DOBBINS 
PO  BOX  07001 7 
HUNTSVILLE  AL  35807-071 7 


63  MITRE  -  BEDFORD 


POC:  Dorothy  Pedersen 
Addr:  THE  MITRE  CORPORATION 
BURLINGTON  ROAD 
MS  1302 

ATTN  DOROTHY  PEDERSEN 
BEDFORD  MA  01730 


103 


5/26/93  EADSIM  Registered  Users  Page:  8 


64 

NATIONAL  TEST  BED  jaNT  PROGRAM  OFFICE 

POC:  Kathy  Stempeck 

Addr:  NATIONAL  TEST  BED  JONT  PROGRAM  OFFICE 

ATTN  KATHY  STEMPECK 

FALCON  AFB,  CO  8091 2-5000 

65 

NAVAL  AIR  WARFARE  CENTER  -  AIRCRAFT  DIVISION 

POC:  DONALD  DAVIS 

Addr:  COMMANDER 

NAVAL  AIR  WARFARE  CENTER(CODE  3021) 

AIRCRAFT  DIVISION  WARMINSTER 

PO  BOX  5152 

WARMINSTER  PA  18974-0591 

66 

NAVAL  AIR  WARFARE  CENTER  -  WEAPONS  DIVISION 

POC:  Harold  Okamoto 

Addr:  COMMANDER  (CODE  C2813) 

NAVAL  AIR  WARFARE  CENTER  -  WEAPONS  DIVISION 

CHINA  LAKE  CA  9355&«001 

67 

NAVAL  POSTGRADUATE  SCHOOL 

POC  LCDR  NEIL  BOURASSA 

Addr:  ATTN  LCDR  NEIL  BOURASSA 

NAVAL  POSTGRADUATE  SCHOOL 

SMC  #2985 

MONTEREY  CA  93943  ^ 

6S 

NAVAL  POSTGRADUATE  SCHOOL 

POC:  MIKE  McCANN 

Addir:  COMPUTER  CENTER  CODE  51 

ATTN  MIKE  MCCANN 

VISUAUZATION  LAB 

NAVAL  POSTGRADUATE  SCHOOL 

MONTEREY  CA  93943 

69 

NAVAL  RESEARCH  LABORATORY  -  INFORMATION  TECHNOLOGY  DIVISION 

POC:  James  A.  Balias 

Addr:  NAVAL  RESEARCH  LABORATORY 

JAMESABALLAS 

CODE  5534 

WASHINGTON  DC  20375-5337 

70 

NAVAL  STRIKE  WARFARE  CENTER 

POC:  MAJ  KEVIN  SCOTT 

Addr:  NAVAL  STRIKE  WARFARE  CENTER,  BLDG  465 

ATTN  CODE  92 

NAVAL  AIR  STATION 

FALLON,  NV  89496-5000 

71 

NAVAL  SURFACE  WARFARE  CENTER 

POC'  Aaron  Goldfarb 

Addr:  NAVAL  SURFACE  WARFARE  CENTER 

10901  NEW  HAMPSHIRE  AVENUE 

ATTN  AARON  GOLDFARB(CODEA41) 

(MS  CODE  D25) 

SILVER  SPRINGS  MD  20903-5000 

72 

NAVAL  SURFACE  WARFARE  CENTER  -  CODE  4032 

POC:  Brent  Waggoner 

Addr:  COMMANDER 

NAVAL  SURFACE  WARFARE  CENTER 

300HWY361 

ATTN  BRENT  WAGGONER  CODE  4032  BUILDING  3212 

CRANE  IN  47522-5050  104 
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73  NAVAL  SURFACE  WARFARE  CENTER  -  DAHLGREN  DIVISION 
POC:  SUZANNE  FORSUNG 
Addr:  COMMANDER 

ATTN  N24BUZANNE  FORSLING 
DAHLGREN  DIVISION 
NAVAL  SURFACE  WARFARE  CENTER 
DAHLGREN  VA  22448-5000 


74  NCCOSC 

POC:  Gary  Carlson 
Addr:  NCCOSC 

NRAD  CODE  852(CARLSON) 
271  CATAUNABLVD 
SAN  DIEGO  CA  92152-5132 


75  NICHOLS  RESEARCH 

POC:  Mike  Pendley 
Addt:  NICHOLS  RESEARCH 
P.O.  BOX  400002 

4040  SOUTH  MEMORIAL  PARKWAY 
ATTN  MIKE  PENDLEY 
HUNTSVILLE  AL  35802 


76  NORTHROP  B-2  DIVISION,  ADVANCED  PROJECTS 
POC:  Charles  T.  Case 
Addr:  NORTHROP  B-2  DIVISION 
ATTN  CHARLES  CASE 
DEPTT211/GS 

8900  EAST  WASHINGTON  BLVD 
PICO  RIVERA  CA  90660-3737 


77  NORTHROP  CORPORATION,  ADVANCED  TECHNOLOGY  AND  DESIGN  CENTER 
POC:  Karen  Aniaza 
Addr.  NORTHROP  CORPORATION 
ATTN  KAREN  ARRIAZA 
DEPT  N410  ZONE  GG 
8900  EAST  WASHINGTON  BLVD 
PICO  RIVERA  CA  90660-3737 


78  NTF  SPECIAL  PROGRAMS  CENTER 
POC:  Capt  Dennis  E.  Nihiser 

Ad*:  DIRECTOR  NTF  SPECIAL  PROGRAMS  CENTER 
ATTN  NIHISER 
NTF/PDT 
730  IRWIN  AVE 
FALCON  AFB  CO  80912-7300 


79  OFFICE  OF  AEROSPACE  STUDIES  AIR  FORCE  SYSTEMS  COMMAND 
POC:  CapL  Kevin  P.  Haupt 
Addr  OAS/AFMC 

ATTN  CAPT  KEVIN  HAUPT 
KIRTLANDAFB  NM  87117 


80  OFFICE  OF  THE  DEPUTY  ASSISTANT  SECRETARY  (STRATEGIC  PROGRAMS) 
POC:  Maj  Michael  Bruhn 
Ad*;  OSD  (PA&E)  SD&SP 

ROOM  2E286  THE  PENTAGON 
WASHINGTON  DC  20301-1800 


8!  OLBB 

POC:  TSGT  GARY  ZIMMERMAN 
Ad*:  GARY  ZIMMERMAN 

1958  SCOTT  DRIVE  SUITE  6 
ELSWORTH  AFB  SD  57706-4710 
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82  OSD  STUDIES  AND  ANALYSIS  DIVISION 
POC:  MAJ  WILLIAM  TARANTINO 
Actt:  MAJOR  TARANTINO  /  JNGO  /  ME670 
DEFENSE  SYSTEMS  SUPPORT  ORG 
7010  PENTAGON 
WASHINGTON  D  C.  20301  -  7010 


83  PEOGPALS.ATMDPO 

POC:  SAM  LAIL,  JR. 

Addt:  PEO,  GPALS 

ATTN  SFAE-GPL-TMD-SI-B  (LAIL) 
PO  BOX  1500 

HUNTSVILLE  AL  35807-3801 


84  PHILLIPS  LABORATORY 

POC:  Lt.  David  Van  Veldhuizen 
Ad*:  LT  DAVID  VAN  VELDHUIZEN 
PHILLIPS  LABORATORY/WST 
3550ABERDEENAVESE 
KIRTLANDAFB  NM  871 17-5776 


85  PLESSEY 

POC:  Paul  Markwardt 

Ad*:  PLESSEY  ELECTRONICS  SYSTEMS  CORPORATION 
15  JACKSON  ROAD 
ATTN  PAUL  MARKWARDT  MS  08A40 
TOTOWA  NJ  07512 


86  QUANTUM 

POC:  Jerry  Rawlinson 
Ad*:  QUANTUM  RESEARCH  INC 
4717  UNIVERSITY  DRIVE 
EXECUTIVE  PLAZA  SUITE  #100 
ATTN  JERRY  RAWLINSON 
HUNTSVILLE  AL  35816 


87  RAND 

POC.  DR.  GREGORY  BORN 
Ad*:  RAND 

ATTN  DR.  BORN 

1700  MAIN  STREET 

SANTA  MONICA  CA  90407-2138 


88  RAYTHEON  COMPANY  -  HUNTSVILLE 

POC:  Richard  K.  Queeney 
Ad*:  RAYTHEON  COMPANY 
353  JAMES  RECORD  ROAD 
ATTN  RICHARD  K.  QUEENEY 
HUNTSVILLE  AL  35824 


89  RAYTHEON  COMPANY  -TEWKSBURY 
POC:  Dr.  Howard 
Ad*:  RAYTHEON  COMPANY 

MISSILE  SYSTEMS  DIVISION 
50  APPLE  HILL  DR. 

ATTN  DR  HOWARD  (T3TG6) 
TEWKSBURY  MA  01876 


90  RDEC 


POC:  Julie  Ellerbeck 
Ad*:  COMMANDER 

US  ARMY  MISSILE  COMMAND 
ATTN  AMSMI-RD-SS-SE(EADSIM) 
REDSTONE  ARSENAL  AL  35898-5252 
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91  RJOJPOET 

POC:  Frank  Handler 
Add^;  FRANK  HANDLER 
RJO-POET 

1225  JEFFERSON  DAVIS  HIGHWAY 
SUITE  300 

ARLINGTON  VA  22202 


92  RJO/POET 

POC:  David  C.  Eissler 
Addr:  RJO/POET 

ATTN  DAVID  C.  EISSLER 
1 745  JEFFERSON  DAVIS  HIGHWAY 
SUITE  1100 

ARLINGTON,  VA  22202 


93  SAIC  -  ARLINGTON 

POC.  Jim  Meagher 
Addt:  CEXEC 

4001  NORTH  FAIRFAX  DRIVE 
SUITE  410 

ATTN  JIM  MEAGHER 
ARLINGTON  VA  22203 


94  SAIC- EL  PASO 

POC:  Bob  Penry 
Addr:  SAIC 

7400  VISCOUNT  BVLD 
SUITE  220 
ATTN  BOB  PENRY 
EL  PASO  TX  79925 


95  SAIC  -  (JPL)MCLEAN 

POC:  John  P.  Lawerence 
Addr;  SAIC/MS 1-6-2 

ATTN  JOHN  LAWERENCE/E.  SIMPSON 
1710GOODRIDGE  DRIVE 
MCLEAN  VA  22102 


%  SAIC  -  (RA)MCLEAN 

POC:  Richard  Aldridge 
Adck:  SAIC 

ATTN  RICHARD  ALDRIDGE 
1710GOODRIDGE  DRIVE 
MAIL  STOP  T2-8-1 
MCLEAN  VA  22102 


97  SOFTWARE  ENGINEERING  DIRECTORATE 
POC:  CAMILLA  GEAN 
Addr:  COMMANDER 

US  ARMY  MISSILE  COMMAND 
ATTN:  AMSMI-RD-BA 
REDSTONE  ARSENAL,  AL  35898-5260 


98  SPARTA  CORPORATION 
POC:  Wai  Lee 
Addr:  SPARTA 

ATTN  WAI  LEE 

7926  JONES  BRANCH  DRIVE 

oiiiTp  onn 

MCLEAN  VA  22102-3303 


99  SPARTA.  INC. 

POC:  John  Segrest 
Addr:  SPARTA  INC 

4901  CORPORATE  DRIVE 
ATTN  JOHN  SEGREST 
HUNTSVILLE  AL  35805 
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100  STWES-ID-T 

POC:  DR.  RAUL  MACHUCA 
Aiddr.  COMMANDER 

US  ARMY  WHITE  SANDS  MISSILE  RANGE 
ATTN  STEWS-ID-TA(DR.  MACHUCA) 

WHITE  SANDS  MISSILE  RANGE  NM  88002-5144 


101  SUMMATECH 

POC  Tom  Shpakowsky 
Ad*:  SUMMA  TECH 

ATTN  TOM  SHPAKOWSKY 
500  DISCOVERY  DRIVE 
HUNTSVILLE  AL  35806 


102  SVERDRUP  TECHNOLOGY  INC 
POC:  Pete  Mahon 

Addr:  SVERDRUP  TECHNOLOGY  INC 
ATTN  PETE  MAHON 
626  ANCHOR  STREET  NW 
SUITE  4 

FORT  WALTON  BEACH  FL  32548 


103  TBE 


POC:  BRAD  COOPER 
Addr:  TELEDYNE  BROWN  ENGINEERING 
300  SPARKMAN  DRIVE 
PO  BOX  070007 
ATTN  BRAD  COOPER 
HUNTSVILLE  AL  35807-7007 


104  TEC-MASTERS,  INC 

POC:  Mike  Bums 
Addr.  TEC-MASTERS  INC 
ATTN  MIKE  BURNS 
1500  PERIMETER  PARKWAY 
SUITE  320 

HUNTSVILLE  AL  35806 


105  TERNION 

POC:  Craig  Korpela 

Addr:  TERNION  CORPORATION 

3307  BOB  WALLACE  AVENUE  SUITE  1 
ATTN  CRAIG  KORPEU 
HUNTSVILLE  AL  35805 


106  THE  AEROSPACE  CORPORATION 
POC:  John  R.  Shure 

Addr:  THE  AEROSPACE  CORPORATION 
ATTN  JOHN  SHURE 
PO  BOX  92957 

ELSEGUNDOCA  90009-2957 


107  TRW  -  HUNTSVILLE 

POC:  Don  Owens 
Addr:  TRW 

213  WYNN  DRIVE 
ATTN  DON  OWENS 
HUNTSVILLE  AL  35805 


108  TRW  -  REDONDO  BEACH 
POC:  Joseph  Swartz 
Ad*:  TRW  (ATTN  JOSEPH  SWARTZ) 

APPLICATIONS  TECHNOLOGY  DIVISION 
MAIL  STOP  R1-1032 
1  SPACE  PARK 
REDONDO  BEACH  CA  90278 
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109  U.  S.  ARMY  CONCE  PTS  ANALYSIS  AGENCY 
POC  Pam  Roberts 

Addr-  U  S  ARMY  CONCEPTS  ANALYSIS  AGENCY 
ATTN  PAM  ROBERTS 
8120  WOODMONT  AVENUE 
BETHESA  MD  20814-2797 


no  U  S.  ARMY  MATERIAL  SYSTEMS  A^  ALYSIS  ACTIVITY  -  AIR  WARFARE  DIVISION 
POC:  Scott  Phillips 

Addr;  U  S.  ARMY  MATERIAL  SYSTEMS  ANALYSIS  ACTIVITY 
ATTN  AMXSY-ADH(PHILLIPS) 

ABERDEEN  PROVING  GROUNDS  MD  21005-5071 


in  U  S.  STRATCOM 

POC;  Lee  Jaramillo 
Add-  .  J534 

US  STRATCOM 
ATTN  LEE  JARAMILLO 
901  SAC  BLVD  SUiTE  2E8 
OFFUTTAFB  NE  68113-6500 


1 12  UNITED  STATES  AIR  FORCE  AIR  COMPONENT  COMMAND  -  JOINT  STUDIES  GROUP 
POC  Capl  Hal  Sommer 
Addr  HQ  ACC/XP-JSG/FD 

ATTN;  CAPT.  HAL  SOMMER 
756  DURAND  ROAD 
LANGLEY  AFB  VA  23665-2595 


1 13  UNITED  STATES  ARMY  STRATEGIC  DEFENSE  COMMAND 
POC;  MAJ  TIM  McKAIG 
Addr;  DEPUTY  COMMANDER 
USASDC 

ATTN  CSSD-SA-SD(MAJ  TIM  MCKA'G) 

PO  BOX  1500 

HUNTSVILLE  AL  35807^1 


114  US  AIR  FORCE  MATERIEL  COMMAND.  ESC/XRPM 
POC  Capl  Curt  Signorino 
Addr;  ESC/XRPM 

ATTN  CAPT  SIGNORINO 
HANSCOMAF8  MA  01731-1624 


1 15  US  ARMY  ARMAMENT  RESEARCH  DEVELOPMENT  3  ENGINEERING  CENTER  (ARDEC) 
POC;  PHILIP  ANGELOTTI 
Addr;  COMMANDER 
US  ARMY  ARDEC 
ATTN  SMCAR-FSS-E(ANGELOTTI) 

PICATINNY  ARSENAL  NJ  07806-5000 


1 16  US  NAVAL  POSTGRADUATE  SCHOOL  -  OPERATIONS  RESEARCH  DEPT 
POC;  LCDR  M  R.  Rios 
Addr;  LCDR  M  R.  RIOS,  USN 

C/O  OPS  RESEARCH  CIRRICULUM  OFFICE 
NAVAL  POSTGRADUATE  SCHOOL 
MONTEREY  CA  93940 


117  USAADASCH  (ATSA-CDF-M) 

POC;  Ray  Cartwright 
Addr;  COMMANDANT 
USAADASCH 

ATTN  ATSA-CDF-M  (RAYMOND  CARTWRIGHT) 
FORT  BUSS  TX  79916^2 
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118  USAP  TAWC  -  EGLIN 

POC:  CPT  Chilcott 
Addr:  OSD  JADO/JE2  JTiE  JTF 
ATTN  CPT  CHILCOTT 
EGUN  APB  FL  32542-5000 


119  USAF  TAWC  -  HURLBURT 
POC:  LTC  CLUSKEY 

Addr.  444 1ST  TACTICAL  TRAINING  GROUP 
ATTN  LTC  CLUSKEY 
HURLBURT  FIELD  FL  32544 


120  USAF/XOXWF 

POC:  CPT  Christopher  Hines 
Addr:  HQ  USAF/XOXWF 

ATTN  CPT  CHRISTOPHER  HINES 
BF922B 

WASHINGTON  DC  20330 


121  USaFc 


POC:  MAJ  Folson 
Addr  HQ  USAFE/DOJW 
ATTN  MAJ  FOLSON 
RAMSTEIN  AB  GE 
APOAE  09094 


122  VEDA 


POC:  Bill  McNellis 
Addr:  VEDA  INC 

5200  SPRINGFIELD  PIKE 
SUITE  200 

ATTN  BILL  MCNELUS 
DAYTON  OH  45431 


123  W.J.  SCHAFER  ASSOCIATES 
POC;  Libby  Jordan 
Addr:  WJ  SCHAFER  ASSOCIATES 
ATTN  LIBBY  JORDAN 
1500  PERIMETER  PARKWAY 
SUITE  470 

HUNTSVILLE  AL  35806 


124  WESTINGHOUSE  ELECTRIC  CORPORATION 
POC:  Elizabeth  M.  Lanier 
Addr:  WESTINGHOUSE  ELECTRIC  CORP 
ATTN  ELIZABETH  LANIER 
PO  BOX  1897  MS  1765 
BALTIMORE  MD  21203 
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